Solution au problème selon lequel 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.

Lors de ma première requête 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 simplement 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 constate 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)

---

En y regardant le lendemain, la requête a encore ralenti. J'étais un peu curieux de savoir si de nouvelles données étaient écrites et si l'index n'était pas mis à jour. .

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!