• 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
Name
Last commit
Last update
..
admin Loading commit data...
client Loading commit data...
lib Loading commit data...
master Loading commit data...
neoctl Loading commit data...
scripts Loading commit data...
storage Loading commit data...
tests Loading commit data...
__init__.py Loading commit data...
debug.py Loading commit data...