Comment comprendre pourquoi une requête MySQL est lente ?


Dans le cadre d’un de mes projets, je suis face à une table de plus d’un million d’entrées sur laquelle je dois effectuer une recherche textuelle, type moteur de recherche. Alors que les requêtes étaient rapides lorsque la table était de taille modérée, le temps d’exécution s’est petit à petit allongé au fil du temps, au fur et à mesure de la croissance de la table. Pour passer de quelques millisecondes à plus d’une seconde d’exécution.

Un cas typique d’une clause WHERE sur un champ non indexé. Après avoir vérifié, tout me semblait pourtant correct de ce côté. C’est alors que je suis tombé sur plusieurs articles présentant le détail du temps d’exécution d’une requête. Quelque chose qui ressemble à ceci:

+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000018 |
| Waiting for query cache lock   | 0.000004 |
| checking query cache for query | 0.000046 |
| checking permissions           | 0.000005 |
| Opening tables                 | 0.000012 |
| System lock                    | 0.000006 |
| Waiting for query cache lock   | 0.000015 |
| init                           | 0.000020 |
| optimizing                     | 0.000008 |
| statistics                     | 0.000029 |
| preparing                      | 0.000018 |
| FULLTEXT initialization        | 0.000453 |
| executing                      | 0.000004 |
| Sorting result                 | 1.274970 |
| Sending data                   | 0.000154 |
| Waiting for query cache lock   | 0.000003 |
| Sending data                   | 0.000061 |
| Waiting for query cache lock   | 0.000003 |
| Sending data                   | 0.000046 |
| Waiting for query cache lock   | 0.000002 |
| Sending data                   | 0.000045 |
| Waiting for query cache lock   | 0.000002 |
| Sending data                   | 0.000043 |
| Waiting for query cache lock   | 0.000002 |
| Sending data                   | 0.000042 |
| Waiting for query cache lock   | 0.000002 |
| Sending data                   | 0.000033 |
| end                            | 0.000004 |
| query end                      | 0.000003 |
| closing tables                 | 0.000007 |
| freeing items                  | 0.000008 |
| Waiting for query cache lock   | 0.000002 |
| freeing items                  | 0.000004 |
| Waiting for query cache lock   | 0.000003 |
| freeing items                  | 0.000002 |
| storing result in query cache  | 0.000003 |
| logging slow query             | 0.000002 |
| cleaning up                    | 0.000003 |
+--------------------------------+----------+
38 rows in set (0.00 sec)

En un coup d’oeil, vous voyez directement d’où vient votre problème: table verrouillée, jointures, tris, … ?

Pour obtenir un tel tableau, rien de plus simple. Connectez-vous à mysql, et tapez la commande suivante:

SET profiling = 1;

Ensuite, tapez votre requête. Une fois celle-ci exécutée, il ne vous reste plus qu’à demander le détail de l’exécution avec

SHOW profile;

Une technique simple et rapide, qui va vous permettre de vérifier votre requêtes SQL et optimiser tout ça pour avoir un site rapide.

facebooktwittergoogle_pluspinterestlinkedintumblrmailfacebooktwittergoogle_pluspinterestlinkedintumblrmail

Laisser un commentaire.