SUBQUERY
ligne de la requête SELECT.
UNCACHEABLE
UNION
Deuxième (ou plus) requête SELECT dans une UNION faite dans une sous-requête qui ne
peut être mise en cache.
table : le nom de la table sur laquelle l'étape est réalisée.
type : le type de jointure utilisée par l'étape. Pour un détail des valeurs possibles, je vous renvoie à la documentation
officielle. Les voici cependant classées du meilleur (du point de vue de la performance) au moins bon : system, const,
eq_ref, ref, fulltext, ref_or_null, index_merge, unique_subquery, index_subquery, range, index, ALL.
possible_keys : les index que MySQL a envisagé d'utiliser pour l'étape.
key : l'index effectivement utilisé
key_len : la taille de l'index utilisé (peut être inférieure à la longueur de l'index en cas d'utilisation d'un index par la
gauche).
ref : indique à quoi l'index sera comparé : une constante (const) ou une colonne.
rows : le nombre estimé de lignes que MySQL devra parcourir pour terminer l'étape (plus ce nombre est petit, mieux c'est).
Extra : donne des informations supplémentaires sur l'étape.
Dans le cas de notre requête SELECT, on a donc 3 étapes :
La clé primaire d'Animal est utilisée et permet de trouver tout de suite la ligne correspondant à notre recherche (id =
37). On ne doit donc parcourir qu'une seule ligne.
En utilisant la valeur d'Animal.espece_id trouvée à l'étape 1, on trouve la ligne correspondante dans la table Espece, à
nouveau en utilisant la clé primaire.
Même chose pour la table Race.
Mais quel est l'intérêt de savoir cela ?
L'intérêt est de pouvoir optimiser ses requêtes. Soit en ajoutant un ou plusieurs index, soit en trouvant la manière optimale
d'écrire la requête.
Savoir sur quelle colonne ajouter un index
Lorsqu'une requête est un peu lente, il est souvent possible de l'accélérer en ajoutant un ou plusieurs index à des endroits
stratégiques. En utilisant EXPLAIN, on peut découvrir facilement quelles étapes de la requête n'utilisent pas d'index, et donc sur
quelles colonnes il peut être intéressant d'ajouter un index.
Exemple
Code : SQL
EXPLAIN SELECT Animal.nom, Adoption.prix, Adoption.date_reservation
FROM Animal
INNER JOIN Adoption ON Adoption.animal_id = Animal.id
WHERE date_reservation >= '2012-05-01' \G
Code : SQL
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: Adoption
type: ALL
possible_keys: ind_uni_animal_id
key: NULL
key_len: NULL
ref: NULL
rows: 24
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
Partie 7 : Gestion des utilisateurs et configuration du serveur
400/414
www.openclassrooms.com
ligne de la requête SELECT.
UNCACHEABLE
UNION
Deuxième (ou plus) requête SELECT dans une UNION faite dans une sous-requête qui ne
peut être mise en cache.
table : le nom de la table sur laquelle l'étape est réalisée.
type : le type de jointure utilisée par l'étape. Pour un détail des valeurs possibles, je vous renvoie à la documentation
officielle. Les voici cependant classées du meilleur (du point de vue de la performance) au moins bon : system, const,
eq_ref, ref, fulltext, ref_or_null, index_merge, unique_subquery, index_subquery, range, index, ALL.
possible_keys : les index que MySQL a envisagé d'utiliser pour l'étape.
key : l'index effectivement utilisé
key_len : la taille de l'index utilisé (peut être inférieure à la longueur de l'index en cas d'utilisation d'un index par la
gauche).
ref : indique à quoi l'index sera comparé : une constante (const) ou une colonne.
rows : le nombre estimé de lignes que MySQL devra parcourir pour terminer l'étape (plus ce nombre est petit, mieux c'est).
Extra : donne des informations supplémentaires sur l'étape.
Dans le cas de notre requête SELECT, on a donc 3 étapes :
La clé primaire d'Animal est utilisée et permet de trouver tout de suite la ligne correspondant à notre recherche (id =
37). On ne doit donc parcourir qu'une seule ligne.
En utilisant la valeur d'Animal.espece_id trouvée à l'étape 1, on trouve la ligne correspondante dans la table Espece, à
nouveau en utilisant la clé primaire.
Même chose pour la table Race.
Mais quel est l'intérêt de savoir cela ?
L'intérêt est de pouvoir optimiser ses requêtes. Soit en ajoutant un ou plusieurs index, soit en trouvant la manière optimale
d'écrire la requête.
Savoir sur quelle colonne ajouter un index
Lorsqu'une requête est un peu lente, il est souvent possible de l'accélérer en ajoutant un ou plusieurs index à des endroits
stratégiques. En utilisant EXPLAIN, on peut découvrir facilement quelles étapes de la requête n'utilisent pas d'index, et donc sur
quelles colonnes il peut être intéressant d'ajouter un index.
Exemple
Code : SQL
EXPLAIN SELECT Animal.nom, Adoption.prix, Adoption.date_reservation
FROM Animal
INNER JOIN Adoption ON Adoption.animal_id = Animal.id
WHERE date_reservation >= '2012-05-01' \G
Code : SQL
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: Adoption
type: ALL
possible_keys: ind_uni_animal_id
key: NULL
key_len: NULL
ref: NULL
rows: 24
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
Partie 7 : Gestion des utilisateurs et configuration du serveur
400/414
www.openclassrooms.com