• 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
neo Loading commit data...
tools Loading commit data...
.gitignore Loading commit data...
BUGS.rst Loading commit data...
CHANGELOG.rst Loading commit data...
COPYING Loading commit data...
MANIFEST.in Loading commit data...
README.rst Loading commit data...
TESTS.txt Loading commit data...
TODO Loading commit data...
UPGRADE.rst Loading commit data...
ZODB.patch Loading commit data...
ZODB3.patch Loading commit data...
importer.conf Loading commit data...
neo.conf Loading commit data...
neoadmin Loading commit data...
neoctl Loading commit data...
neolog Loading commit data...
neomaster Loading commit data...
neomigrate Loading commit data...
neostorage Loading commit data...
setup.py Loading commit data...