[MDEV-22054] Very bad performance MariaDB vs MySQL Created: 2020-03-26  Updated: 2023-09-19

Status: Open
Project: MariaDB Server
Component/s: Optimizer, Query Cache
Affects Version/s: 10.4.12
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Pascal ROBINET Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Alpine Linux 3.11



 Description   

Hello,
after upgrading from MySQL 5.7.12 to MariaDB 10.4.12 we see a nasty drop in performances which render our software unusable. I experimented with MySQL 5.7.29 and the result is the same.
I tracked down the issue to a x6 drop in speed for some cached queries in MariaDB.
Here are the initial queries, with no caching involved :

SELECT COUNT(*) FROM `products_views` INNER JOIN `users` ON `users`.`id` = `products_views`.`user_id` WHERE (products_views.created_at between '2020-03-09 00:00:00.000000' and '2020-03-20');
+----------+
| COUNT(*) |
+----------+
|   185202 |
+----------+
1 row in set (11.26 sec)

while with MySQL 5.7.29 I get :

SELECT COUNT(*) FROM `products_views` INNER JOIN `users` ON `users`.`id` = `products_views`.`user_id` WHERE (products_views.created_at between '2020-03-09 00:00:00.000000' and '2020-03-20');
+----------+
| COUNT(*) |
+----------+
|   165805 |
+----------+
1 row in set (7.96 sec)

Afterward the cache is primed and things gets ugly for MariaBD when I repeat the same query :

  • MariaDB (8.92 sec with some variations)
  • MySQL the time is constant, always 2.05 sec.

The EXPLAIN shows both software have a very different way of running this very same query :

MariaDB

+------+-------------+----------------+-------+---------------------------------+---------------------------------+---------+--------------------------------+--------+-------------+
| id   | select_type | table          | type  | possible_keys                   | key                             | key_len | ref                            | rows   | Extra       |
+------+-------------+----------------+-------+---------------------------------+---------------------------------+---------+--------------------------------+--------+-------------+
|    1 | SIMPLE      | users          | index | PRIMARY                         | index_users_on_followers_count  | 4       | NULL                           | 226050 | Using index |
|    1 | SIMPLE      | products_views | ref   | index_products_views_on_user_id | index_products_views_on_user_id | 5       | pf_analytics_int_prod.users.id | 15     | Using where |
+------+-------------+----------------+-------+---------------------------------+---------------------------------+---------+--------------------------------+--------+-------------+

MySQL

+----+-------------+----------------+------------+--------+---------------------------------+---------+---------+-----------------------------------+---------+----------+-------------+
| id | select_type | table          | partitions | type   | possible_keys                   | key     | key_len | ref                               | rows    | filtered | Extra       |
+----+-------------+----------------+------------+--------+---------------------------------+---------+---------+-----------------------------------+---------+----------+-------------+
|  1 | SIMPLE      | products_views | NULL       | ALL    | index_products_views_on_user_id | NULL    | NULL    | NULL                              | 6159146 |    11.11 | Using where |
|  1 | SIMPLE      | users          | NULL       | eq_ref | PRIMARY                         | PRIMARY | 4       | pf_app_pub.products_views.user_id |       1 |   100.00 | Using index |
+----+-------------+----------------+------------+--------+---------------------------------+---------+---------+-----------------------------------+---------+----------+-------------+

I experimented a bit with some optimizations but to not avail. MariaDB optimizer is not up to par with MySQL but it's mostly the cache that is way better in MySQL.
Profiling shows all the time is spent in "Sending data" phase, both for MariaDB and MySQL.



 Comments   
Comment by Elena Stepanova [ 2020-04-05 ]

Did you paste the right queries? You are reporting x6 drop, but according to your output, it's 11.3 sec vs 8 sec, and the contents / size of the table is different, too (the query for MariaDB returns higher count).
Can you provide a data sample (table structures and table data) which shows the problem? While doing so, please also paste or attach your config files.
If you don't want to make the information public, you can upload it to ftp.askmonty.org/private.

Comment by Pascal ROBINET [ 2020-04-06 ]

Hi and thanks for the answer,
yes sorry I wasn't clear, the x6 drop is for subsequent queries, 8 secs is at cold start (bypassing cache). When it's warmed up, which is almost always the case, you consistently get a 2 secs time in MySQL vs a varying 11 to 12 secs in MariaDB, you have in in the 2nd part of my post.
In the end the user experiences an acceptable loading time with MySQL while it raises to 2 mins and a half with MariaDB
The different results you mention could come from my dev BD (migrated to MariaDB) lagging behind prod (MySQL), it is only synced from prod from time to time, so there is some missing data but nothing that could impact the perfs.
I will send you table structure.

Comment by Pascal ROBINET [ 2020-04-15 ]

Hi, I see you labeled as "Need Feedback", why so ? There is no other precision.
I answered in my previous comment and sent the table structure via the upload you mentionned.

Thanks

Comment by Axel Schwenke [ 2020-06-23 ]

sorry, I didn't see your mention of an upload.

Comment by Pascal ROBINET [ 2022-04-12 ]

Hi, any progress on this issue ?

Comment by Daniel Black [ 2022-11-25 ]

axel DDL_tables_perf_query_mariadb-MDEV22054.txt is still on the ftp server.

Comment by Pascal ROBINET [ 2022-11-25 ]

It would be great to see this issue solved so we can at last switch our workload to MariaDB.

Comment by Pascal ROBINET [ 2023-08-14 ]

Hi, any update on this bug please ?

I updated the description to be more precise, taking into account @elenst comment

Comment by Sergei Golubchik [ 2023-09-05 ]

There are few things you could try to understand what's happening better.

You can exclude the optimizer differences by forcing the same query plan in MariaDB and in MySQL. STRAIGHT JOIN and FORCE INDEX can make the optimizer to use a specific join order or a specific index.

Then, innodb_flush_method. It affects whether InnoDB will be using filesystem cache or not.

The size of the innodb buffer pool matters too, that's one of the few most important variables to tune.

Comment by Pascal ROBINET [ 2023-09-14 ]

Hi Sergei and thanks for your answer but I'm not sure to understand your comment, do you need more input from my side to pinpoint the root cause ?

If so could you be a bit more precise about your needs please ? Do you need me to run some tests with different values ? If so which values please ?
And which requests do you need me to run ?

Comment by VAROQUI Stephane [ 2023-09-14 ]

Having probably a stupid question , Can't you just remove the user table from the query ?

Comment by VAROQUI Stephane [ 2023-09-14 ]

Please try to ANALYSE TABLE users, products_views PERSISTENT FOR ALL and see if explain change

Comment by Pascal ROBINET [ 2023-09-19 ]

Of course we can't remove the table @stephane@skysql.com, we don't just randomly dump tables into a query

And anyway the issue is about a bad performance of MariaDB optimizer compared to MySQL, which needs to be fixed to avoid people dropping MariaDB in favor of MySQL.

The analysis and timing I provided comes mainly from ANALYSE TABLE results.

Generated at Thu Feb 08 09:11:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.