MySQL Reference Manual :: 7.2.1 Syntaxe de EXPLAIN (Obtenir des informations sur les SELECT)

SIMPLE

SELECT simple (sans utiliser de clause UNION ou de sous-requêtes).

PRIMARY

SELECT extérieur.

UNION

Second et autres UNION SELECTs.

DEPENDENT UNION

Second et autres UNION SELECTSs, dépend de la commande extérieure.

SUBQUERY

Premier SELECT de la sous-requête.

DEPENDENT SUBSELECT

Premier SELECT, dépendant de la requête extérieure.

DERIVED

Table dérivée SELECT.

system

La table a une seule ligne (c'est une table système). C'est un cas spécial du type de jointure const.

const

La table a au plus une ligne correspondante, qui sera lue dès le début de la requête. Comme il n'y a qu'une seule ligne, les valeurs des colonnes de cette ligne peuvent être considérées comme des constantes pour le reste de l'optimiseur. Les tables const sont très rapides, car elles ne sont lues qu'une fois.

const est utilisé lorsque vous comparez toutes les parties d'une clé PRIMARY/UNIQUE avec des constantes :

SELECT * FROM const_table WHERE primary_key=1;

SELECT * FROM const_table
WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref

Une ligne de cette table sera lue pour chaque combinaison de ligne des tables précédentes. C'est le meilleur type de jointure possible, à l'exception des précédents. Il est utilisé lorsque toutes les parties d'un index sont utilisées par la jointure, et que l'index est UNIQUE ou PRIMARY KEY.

eq_ref peut être utilisé pour les colonnes indexées, qui sont comparées avec l'opérateur =. L'élément comparé doit être une constante ou une expression qui utiliser les colonnes de la table qui est avant cette table.

Dans l'exemple suivant, ref_table sera capable d'utiliser eq_ref :

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

ref

Toutes les lignes avec des valeurs d'index correspondantes seront lues dans cette table, pour chaque combinaison des lignes précédentes. ref est utilisé si la jointure n'utilise que le préfixe de gauche de la clé, ou si la clé n'est pas UNIQUE ou PRIMARY KEY (en d'autres termes, si la jointure ne peut pas sélectionner qu'une seule ligne en fonction de la clé). Si la clé qui est utilisée n'identifie que quelques lignes à chaque fois, la jointure est bonne.

ref peut être utilisé pour les colonnes indexées, qui sont comparées avec l'opérateur =.

Dans les exemples suivants, ref_table sera capable d'utiliser ref.

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

ref_or_null

Comme ref, mais avec le coût supplémentaire pour les recherches couvrant les valeurs NULL. Ce type de jointure est nouveau en MySQL 4.1.1 est sert essentiellement à la résolution des sous-requêtes.

Dans les exemples suivants, MySQL peut utiliser une jointure ref_or_null pour traiter ref_table :

SELECT * FROM ref_table
WHERE key_column=expr OR key_column IS NULL; 

See Section 7.2.7, « Comment MySQL optimise IS NULL ».

index_merge

Ce type de jointure indique que l'optimisation de type Index Merge est utilisée. Dans ce cas, la colonne key contient une liste d'index utilisés, et key_len contient la liste des plus longues parties de clés utilisées. Pour plus d'informations, voyez Section 7.2.6, « Optimisation de combinaison d'index ».

unique_subquery

Ce type remplace le type ref dans certaines sous-requêtes IN de la forme suivante :

value IN (SELECT primary_key FROM single_table WHERE some_expr) 

unique_subquery est simplement une analyse d'index, qui remplace complètement la sous-requête pour une meilleure efficacité.

index_subquery

Ce type de jointure est similaire à unique_subquery. Elle remplace des sous-requêtes IN, mais elle fonctionne pour les index non-uniques dans les sous-requêtes de la forme suivante :

value IN (SELECT key_column FROM single_table WHERE some_expr) 

range

Seules les lignes qui sont dans un intervalle donné seront lues, en utilisant l'index pour sélectionner les lignes. La colonne key indique quel est l'index utilisé. key_len contient la taille de la partie de la clé qui est utilisée. La colonne ref contiendra la valeur NULL pour ce type.

range peut être utilisé lorsqu'une colonne indexée est comparée avec une constante comme =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN ou IN.

SELECT * FROM tbl_name
WHERE key_column = 10;

SELECT * FROM tbl_name
WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
WHERE key_part1= 10 AND key_part2 IN (10,20,30);

index

C'est la même chose que ALL, hormis le fait que seul l'arbre d'index est étudié. C'est généralement plus rapide que ALL, car le fichier d'index est plus petit que le fichier de données.

Cette méthode peut être utilisée lorsque la requête utilise une colonne qui fait partie d'un index.

ALL

Une analyse complète de la table sera faîte pour chaque combinaison de lignes issue des premières tables. Ce n'est pas bon si la première table n'est pas une jointure de type const et c'est très mauvais dans les autres cas. Normalement vous pouvez éviter ces situations de ALL en ajoutant des index basée sur des parties de colonnes.

Distinct

MySQL ne va pas continuer à chercher d'autres lignes que la ligne courante, après en avoir trouvé une.

Not exists

MySQL a été capable d'appliquer une optimisation de type LEFT JOIN sur la requête, et ne va pas examiner d'autres lignes de cette table pour la combinaison de lignes précédentes, une fois qu'il a trouvé une ligne qui satisfait le critère de LEFT JOIN.

Voici un exemple de cela :

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;

Supposons que t2.id est défini comme NOT NULL. Dans ce cas, MySQL va scanner t1 et rechercher des lignes dans t2 via t1.id. Si MySQL trouve une ligne dans t2, il sait que t2.id ne peut pas être NULL, et il ne va pas scanner le reste des lignes de t2 qui ont le même id. En d'autres termes, pour chaque ligne de t1, MySQL n'a besoin que de faire une recherche dans t2, indépendamment du nombre de lignes qui sont trouvées dans t2.

range checked for each record (index map: #)

MySQL n'a pas trouvé d'index satisfaisant à utiliser. Il va, à la place, pour chaque combinaison de lignes des tables précédentes, faire une vérification de quel index utiliser (si il en existe), et utiliser cet index pour continuer la recherche. Ce n'est pas très rapide, mais c'est plus rapide que de faire une recherche sans aucun index.

Using filesort

MySQL va avoir besoin d'un autre passage pour lire les lignes dans l'ordre. Le tri est fait en passant en revue toutes les lignes, suivant le type de jointure est stocker la clé de tri et le pointeur de la ligne pour chaque ligne qui satisfont la clause WHERE. Alors, les clés sont triées. Finalement, les lignes sont triées dans l'ordre.

Using index

Les informations de la colonne sont lues de la table, en utilisant uniquement les informations contenues dans l'index, sans avoir à faire d'autres lectures. Cela peut arriver lorsque toutes les colonnes utilisées dans une table font partie de l'index.

Using temporary

Pour résoudre la requête, MySQL va avoir besoin de créer une table temporaire pour contenir le résultat. C'est typiquement ce qui arrive si vous utilisez une clause ORDER BY sur une colonne différente de celles qui font partie de GROUP BY.

Using where

Une clause WHERE sera utilisée pour restreindre les lignes qui seront trouvées dans la table suivante, ou envoyée au client. Si vous n'avez pas cette information, et que la table est de type ALL ou index, vous avez un problème dans votre requête (si vous ne vous attendiez pas à tester toutes les lignes de la table).