I am having a strange issue with a slow query under certain conditions: I have made a few tests and was able to isolate the issue to one single table called products_description (all the tables are MyISAM). At first I noticed that when this table is new (ie. just imported), the query always performs fast (~0.3s). However, if I perform any of these operations on this specific table, at any time (even immediately after importing it): CHECK, OPTIMIZE, ANALYZE or REPAIR, the query suddenly slows down x10 times (takes ~4.5s) and keeps staying always slow.

Note that I forced no-caching when running the query to ensure the results are correct.

I am able to restore the performance only if I am then performing any of these operations on that table:

1) DROP the table and import it again.


2) ALTER any of the following of that table: Collation or CHECKSUM or DELAY_KEY_WRITE. It then runs fast with the altered value and when reverting back to the old value, the performance remains fast.

Even then, if I perform any of the CHECK, OPTIMIZE, ANALYZE or REPAIR operations on that table, the query speed drops until I do either 1) or 2)

One more thing I tested: Before performing any operation on the table, I backed up the table's files (products_description.frm, products_description.MYD, products_description.MYI), ran the query, it ran fast. Then I performed CHECK on the table, ran the query, speed was x10 times slower, I copied the backed up files and overwrote the 3 files, ran the query again, slow speed again.

I have compressed the database in a ~5mb zip file (~80mb unzipped). If anyone wants to test the database in your own environment, please let me know and I will send you a download link. I could reproduce this on several different servers, on both MariaDB 10.1+ and MySQL 5.6+.

This is the SQL query that I am running and you should test with:

SELECT DISTINCT pav.products_options_values_id, 
FROM   products_stock ps, 
       products_options_values pav, 
       (SELECT DISTINCT pa.products_id 
        FROM   products_attributes pa, 
               products_options_values pov, 
               (SELECT p.products_id, 
                       IF(s.status, s.specials_new_products_price, NULL) 
                       IF(s.status, s.specials_new_products_price, 
                       p.products_price) AS 
                       IF(p.clearance_price < p.products_cost * 2.25, 
                       p.products_cost * 2.25) 
                FROM   products p 
                       LEFT JOIN specials s 
                              ON p.products_id = s.products_id 
                       LEFT JOIN products_description pd 
                              ON p.products_id = pd.products_id 
                 p.products_status = '1' 
                 AND Date_sub('2016-04-19', INTERVAL 7000 day) <= 
               ) m 
        WHERE  m.products_id = pa.products_id 
               AND pa.options_id = 1 
               AND pa.options_values_id = pov.products_options_values_id 
               AND pov.language_id = '1') q 
WHERE  q.products_id = ps.products_id 
       AND ps.products_stock_attributes = 
           Concat('1-', pav.products_options_values_id) 
       AND ps.products_stock_quantity > 0 
ORDER  BY pav.products_options_values_sort_order ASC 

Here are the EXPLAIN EXTENDED results. Seems like the optimizer is working differently on both tables, but that doesn't really explain why that happens, as the copied database is supposedly identical.

Slow database's EXPLAIN

Fast database's EXPLAIN

These are the screenshots of the profiling of the query on the slow and fast database:

Slow database profiling Fast database profiling

What can be the possible causes for this huge discrepancy and how can they be verified and fixed?

P.S. I posted this question on stackexchange and was advised to ask the experts here.


1 Answer 1


Seems like I forgot to answer my own question for a while. Apparently I have discovered quite a serious bug in the MySQL/MariaDB engine and/or optimizer.

This bug has been reported (both to Oracle and Maria) and reproduced (confirmed) by MariaDB staff (Elena Stepanova), who already assigned it to one of their lead developers (Sergei Petrunia) and Varun Gupta. I believe it will probably be fixed quite soon, as the report was made on 2016 and their patch seems to be in final stages ("In Review" at the time of writing this): https://jira.mariadb.org/browse/MDEV-9959

With Oracle tho, well, a different story entirely...

UPDATE (November 20th, 2019): As of MariaDB 10.3.15 & 10.4.5 this bug is finally fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.