[MDEV-9789] MariaDB 10.1 SELECT significantly slower vs MariaDB 5.5 Created: 2016-03-24 Updated: 2016-11-29 Resolved: 2016-11-29 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | OTHER |
| Affects Version/s: | 5.5.44, 10.0.25, 10.1.12 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | John McGuire | Assignee: | Axel Schwenke |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Dell PowerEdge R730 Server |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Sprint: | 10.2.4-2 | ||||||||
| Description |
|
Update 2: Added benchmark items from MariaDB 10.0.25 instance. Update 1: Added benchmark items from MySQL 5.5.25a instance. Original Post I am looking to upgrade a MySQL 5.5.45 server to MariaDB. I have two identical machines (info above), and I have installed one version of MariaDB on each (5.5.44-MariaDB; 10.1.12-MariaDB) via the MariaDB yum repo. Both are based off of a xtrabackup of the existing MySQL server, with neither currently replicating. The data table that I am testing on has a large amount of weather data (423M rows x 240 columns). When I run the query below, I get a much slower query time on 10.1 than I do on 5.5. Here is a sample of benchmark times. For comparison, I have also included the MySQL 5.5.25a instance running on a five year old RHEL6 box. 10.1.12-MariaDB: 13560 rows in set (2.66 sec) Any thoughts or ideas would be greatly appreciated. I would be happy to provide more info, if needed to solve this issue. Thanks,
QUERY: Please note that the times below happen to be identical for every station, but this is not always the case. This is done just for a simplified example.
5.5.44-MariaDB: EXPLAIN of above query
10.0.25-MariaDB: EXPLAIN of above query
10.1.12-MariaDB: EXPLAIN of above query
5.5.25a-MySQL EXPLAIN of above query
TABLE STRUCTURE:
|
| Comments |
| Comment by Elena Stepanova [ 2016-03-25 ] | ||||||||||||||||||||||||||||||||||||||||
|
wxjam, | ||||||||||||||||||||||||||||||||||||||||
| Comment by John McGuire [ 2016-03-25 ] | ||||||||||||||||||||||||||||||||||||||||
|
Elena, I have updated my original post with MySQL 5.5.25a benchmarks (5 year old operational server on RHEL6). | ||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2016-03-30 ] | ||||||||||||||||||||||||||||||||||||||||
|
wxjam, I tried to reproduce it, although I didn't get anywhere near the size of your table, but on 3,5M rows and with 2G buffer pool the first query (on both 5.5 and 10.1 servers) takes several seconds, while the next ones are nearly instant – 0.01 second and such. | ||||||||||||||||||||||||||||||||||||||||
| Comment by John McGuire [ 2016-03-30 ] | ||||||||||||||||||||||||||||||||||||||||
|
@elenst Both of my MariaDB server benchmarks are from a cold database. I am most concerned about the cold database due to the nature of the data I am using, since the WHERE clause will always be different, using different combinations of stations and date ranges. I have not tried the ANALYZE TABLE before, but below are benchmarks using that: Query only: Analyze table, then query: | ||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2016-04-18 ] | ||||||||||||||||||||||||||||||||||||||||
|
axel, | ||||||||||||||||||||||||||||||||||||||||
| Comment by John McGuire [ 2016-04-27 ] | ||||||||||||||||||||||||||||||||||||||||
|
Please let me know if there are any other tests that I can run to help try to resolve this issue. Thanks | ||||||||||||||||||||||||||||||||||||||||
| Comment by Axel Schwenke [ 2016-06-28 ] | ||||||||||||||||||||||||||||||||||||||||
|
Hi John, please excuse the long delay. I hope you haven't given up on MariaDB yet. By looking at your table definition and query I notice that you use the following WHERE condition: (station = 'num1' AND ob >= 'num2' AND ob <= 'num3') where num1, num2 and num3 are all numerical literals. In case of `station` this is fine, as it is defined as VARCHAR(10). However `ob` is a DATETIME and as such should be compared to either a string reprentation of the form 'YYYY-MM-DD HH:MM:SS' or to a plain number of the form YYYYMMDDHHMMSS. Could you please repeat your test, but this time do not put quotes around the numbers you compare the `ob` column with? In other words: WHERE (station = '31044' AND ob >= 20160310000000 AND ob <= 20160310120000) OR ... | ||||||||||||||||||||||||||||||||||||||||
| Comment by Axel Schwenke [ 2016-11-15 ] | ||||||||||||||||||||||||||||||||||||||||
|
I tried to reproduce the behavior with MariaDB 5.5.49 vs. 10.0.27 vs. 10.1.8. No success. No matter if the timestamp literals are quoted (which is wrong) or not - I get the same performance. Between the releases I see strictly better performance from 10.0 over 5.5 and same performance from 10.1 vs. 10.0. Here are queries per second for doing range scans (station=const AND ob>=start AND ob<=end) on a table with 800.000 rows. Once with the literals for start and end in quotes and once without quotes. `ob` unquoted
`ob` quoted
| ||||||||||||||||||||||||||||||||||||||||
| Comment by John McGuire [ 2016-11-16 ] | ||||||||||||||||||||||||||||||||||||||||
|
Sorry Axel, I didn't see the notification from June with your comment about the DATETIMEs. I had modified this query in the past to try to avoid this slowdown issue, but I am interested to see this bug through to its completion. I had to give up my 10.0.x MariaDB box due to server demand, so I only have MariaDB 10.1.17 and MySQL 5.5.25a (phased retirement) servers to test on now. With 10.1.17 on a cold start, I now get MySQL 5.5.25a: Benchmarks are much closer with each other now. Were there any potential enhancements between 10.1.12 and 10.1.17 that could explain this? | ||||||||||||||||||||||||||||||||||||||||
| Comment by Axel Schwenke [ 2016-11-29 ] | ||||||||||||||||||||||||||||||||||||||||
|
Hi John, there were literally 100s of changes between 10.1.12 and 10.1.17. However none of them sticks out with regard to SQL performance. Nor do I remember any known performance issues specifically in 10.1.12. |