La solution à l'index MySQL ne prend pas effet

Le mysql utilisé par l'entreprise pour les services a été très lent récemment lors des requêtes. Cela prend souvent plus de 10 secondes. J'ai vérifié le plan d'exécution de la requête et j'ai constaté que l'index ne prenait pas effet.

Le moteur de stockage utilise InnoDB.

Lorsque j'ai interrogé pour la première fois dans la base de données principale, j'étais toujours curieux de savoir pourquoi l'index ne prenait pas effet. Après être passé à la base de données de secours, j'ai constaté que la base de données de secours était efficace.

J'ai commencé à me demander s'il y avait un problème avec l'index, puis j'ai reconstruit l'index et j'ai constaté que l'efficacité était beaucoup plus élevée.

Enregistrez brièvement la comparaison.

mysql> explain select * from runinfo where status in (0, 2, 1, 3, 4, 7, 9, 10);
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
| id | select_type | table   | type  | possible_keys | key  | key_len | ref  | rows     | Extra       |
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
|  1 | SIMPLE      | runinfo | All   | status_2      | NULL | NULL    | NULL |  2378055 | Using where |
+----+-------------+---------+-------+---------------+------+---------+------+----------+-------------+
row in set (0.00 sec)

Ce qui précède est le plan d'exécution de la bibliothèque principale.

Comparez le plan d'exécution de la base de données de secours.

mysql> explain select * from runinfo where status in (0, 2, 1, 3, 4, 7, 9, 10);
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key      | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
|  1 | SIMPLE      | runinfo | range | status_2      | status_2 | 4       | NULL |  116 | Using where |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-------------+
row in set (0.00 sec)

On voit que la base de données de secours s'adapte à l'index status_2 lors de la requête.

Après avoir exécuté la commande suivante, le problème est résolu.

mysql> OPTIMIZE TABLE runinfo;
+------------------+----------+----------+-------------------------------------------------------------------+
| Table            | Op       | Msg_type | Msg_text                                                          |
+------------------+----------+----------+-------------------------------------------------------------------+
| schedule.runinfo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| schedule.runinfo | optimize | status   | OK                                                                |
+------------------+----------+----------+-------------------------------------------------------------------+
rows in set (47.13 sec)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!