• Julien Muchembled's avatar
    mysql: fix use of wrong SQL index when checking for dropped partitions · 13911ca3
    Julien Muchembled authored
    After partitions were dropped with TokuDB, we had a case where MariaDB 10.1.14
    stopped using the most appropriate index.
    
    MariaDB [neo0]> explain SELECT DISTINCT data_id FROM obj WHERE `partition`=5;
    +------+-------------+-------+-------+-------------------+---------+---------+------+------+---------------------------------------+
    | id   | select_type | table | type  | possible_keys     | key     | key_len | ref  | rows | Extra                                 |
    +------+-------------+-------+-------+-------------------+---------+---------+------+------+---------------------------------------+
    |    1 | SIMPLE      | obj   | range | PRIMARY,partition | data_id | 11      | NULL |   10 | Using where; Using index for group-by |
    +------+-------------+-------+-------+-------------------+---------+---------+------+------+---------------------------------------+
    MariaDB [neo0]> SELECT SQL_NO_CACHE DISTINCT data_id FROM obj WHERE `partition`=5;
    Empty set (1 min 51.47 sec)
    
    Expected:
    
    MariaDB [neo1]> explain SELECT DISTINCT data_id FROM obj WHERE `partition`=4;
    +------+-------------+-------+------+-------------------+---------+---------+-------+------+------------------------------+
    | id   | select_type | table | type | possible_keys     | key     | key_len | ref   | rows | Extra                        |
    +------+-------------+-------+------+-------------------+---------+---------+-------+------+------------------------------+
    |    1 | SIMPLE      | obj   | ref  | PRIMARY,partition | PRIMARY | 2       | const |    1 | Using where; Using temporary |
    +------+-------------+-------+------+-------------------+---------+---------+-------+------+------------------------------+
    1 row in set (0.00 sec)
    MariaDB [neo1]> SELECT SQL_NO_CACHE DISTINCT data_id FROM obj WHERE `partition`=4;
    Empty set (0.00 sec)
    
    Restarting the server or 'OPTIMIZE TABLE obj; ' does not help.
    
    Such issue could prevent the cluster to start due to timeouts, by always going
    back to RECOVERING state.
    13911ca3
mysqldb.py 31.5 KB