| Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT ) <<< |
Mesurer les performances d'une requête | Vitesse des requêtes SELECT >>> |
7.2 Optimisation des commandes SELECT et autres requêtes 7 Optimisation de MySQL Manuel de Référence MySQL 4.1 : Version Française . Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT ) ->Mesurer les performances d'une requête . Vitesse des requêtes SELECT . Comment MySQL optimise les clauses WHERE . Comment MySQL optimise la condition OR . Comment MySQL optimise IS NULL . Comment MySQL optimise DISTINCT . Comment MySQL optimise les clauses LEFT JOIN et RIGHT JOIN . Comment MySQL optimise ORDER BY . Comment MySQL optimise LIMIT . Comment éviter les scans de tables,,, . Vitesse des requêtes INSERT . Vitesses des commandes UPDATE . Rapidité des requêtes DELETE . Autres conseils d'optimisation |
7.2.2 Mesurer les performances d'une requête
Dans la plupart des cas, vous pouvez mesurer la performance d'une requête en comptant le nombre d'accès disques. Pour les tables de petite taille, vous pouvez généralement obtenir une seule lecture (car l'index est probablement en cache). Pour les tables plus grandes, vous pouvez estimer que vous aurez besoin de (en utilisant les index B-tree ) : log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1 lectures pour trouver une ligne. Pour MySQL, un bloc d'index vaut généralement 1024 octets, et le pointeur de données vaut 4 octets. Une table de 500,000 avec un index de taille 3 (entier moyen) vous donnera : log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 lectures. Comme l'index ci-dessus vous serait de taille 500 000 * 7 * 3/2 = 5.2 Mo, (en supposant que les index des tampons sont remplit aux 2/3, ce qui est typique), vous aurez probablement l'essentiel de l'index en mémoire, et vous n'aurez alors besoin que de 1 ou 2 lectures pour lire le reste des lignes.Pour les écritures, toutefois, vous aurez besoin de 4 lectures (comme ci-dessus), pour trouver la place du nouvel index, et normalement, deux autres lectures pour modifier l'index et la ligne. Notez que le raisonnement ci-dessus n'indique pas que votre application va dégénérer en fonction du logarithme népérien! Tant que tout est mis en cache par l'OS ou le serveur SQL, les performances ne vont se réduire que marginalement, même si la table grossit beaucoup. Une fois que les données seront trop importantes pour être en cache, votre application va ralentir car le serveur devra faire des lectures sur le disque (ce qui va accroître le log). Pour éviter cela, augmentez le cache d'index au fur et à mesure que votre index grossit. Choix des paramètres du serveur . |
| << | Mesurer les performances d'une requête | >> |
| Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT ) | Optimisation des commandes SELECT et autres requêtes | Vitesse des requêtes SELECT |