SQL Optimization

Evaluation of the plan before the execution of the query

The SQL EXPLAIN command (or its synonym DESCRIBE) describes the plan for
executing a query, based in particular on the statistics of the tables and
their indexes. Place the word EXPLAIN at the beginning of the query:
EXPLAIN SELECT * FROM CLIENT WHERE name like ’ab%’\G

There is a system variable that after each EXPLAIN evaluates the cost of the parsed query. This is the
Last_query_cost variable:

SHOW STATUS LIKE 'last_query_%';

mysql> SHOW STATUS LIKE 'last_query_%';

+--------------------------+----------+

| Variable_name | Value |

+--------------------------+----------+

| Last_query_cost | 1.199000 |

| Last_query_partial_plans | 1 |

+--------------------------+----------+

The cost of the last query analyzed is 1.199000. The advantage of this variable is that it evaluates the
cost of a query without imposing its execution. The method of calculating the displayed value is rather
obscure, but it remains interesting to follow its evolution after each modification and EXPLAIN of a
request, if only to succeed in minimizing it.

Another system variable prefixed by Last_query% is Last_query_partial_plan, added in version 5.6.5 of

MySQL. Its value indicates the number of iterations performed by the optimizer to arrive at the optimal
execution plan.
EXPLAIN has EXTENDED and PARTITION options that provide additional
information about the execution plan and any partitions involved. Both
options are enabled by default since MySQL version 5.7.3.

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

Column Meaning

id Designates the identifier of the column used for the sequential

browsing of the table. In the case where this identifier would result
from the association of two or more columns, the displayed value
 is NULL, and the table column indicates the details of this
association: <unionN, M>.

select_type Renseigne sur la catégorie du SELECT.

SIMPLE : pas d’union avec un autre SELECT, ni de sous-requête.
PRIMARY : il s’agit d’un SELECT externe, c’est-à-dire du premier SELECT,
hors de toute vue ou sous-requête.
UNION : il s’agit d’un SELECT dans un UNION.
DEPENDENT UNION : il s’agit d’un SELECT dans un UNION dépendant
d’une requête externe (parce que lui-même inclus dans une sous-requête corrélée
par exemple).
UNION RESULT : résultat d’un UNION.
SUBQUERY : premier SELECT d’une sous-requête.
DEPENDENT SUBQUERY : premier SELECT d’une sous-requête,
dépendant d’une requête externe.
DERIVATED : SELECT dans la sous-requête d’une clause FROM.
MATERIALIZED : sous-requête que l’optimiseur a jugé utile de matérialiser
sous la forme d’une table temporaire. Implique que la variable système
optimizer_switch comporte l’option materialized=ON.
UNCACHEABLE SUBQUERY : sous-requête dont le résultat ne peut être
stocké en cache et doit être recalculé pour chaque ligne (très coûteux, à éviter le cas
échéant !).
UNCACHEABLE UNION : deuxième SELECT (ou plus) appartenant à une
sous-requête dont le résultat ne peut être stocké en mémoire cache.

table Table à laquelle la ligne est associée. Peut aussi avoir l’une des valeurs suivantes :
<unionM,N> : la ligne fait référence à l’union de deux lignes, dont les id
respectifs se réfèrent aux colonnes M et N.
<derivedN> : la ligne se réfère au résultat de la table dérivée ayant comme id
la colonne N. Une table dérivée peut résulter, par exemple, de la sous-requête d’une
clause FROM.
<subqueryN> : la ligne fait référence à la table résultant d’une sous-requête
matérialisée ayant pour id la colonne N.

partitions Partitions impliquées.

type Type de jointure. Les différents types de jointures possibles sont les suivants :
system : la table ne possède qu’une ligne et il s’agit d’une table système. C’est
un cas particulier du type const vu ci-après.
const : la table n’a qu’une ligne impliquée dans la requête, cette ligne est lue en
début de traitement.
eq_ref : une seule ligne est mise en correspondance avec les lignes des autres
tables en jointure. Après system et const, c’est le meilleur cas de figure
possible.
ref : toutes les lignes de la table mises en correspondance sont lues en s’appuyant
sur l’index, bien que plusieurs résultats soient possibles. La jointure ne peut
sélectionner qu’une seule ligne pour chaque valeur de l’index. Par conséquent, une
jointure de type ref reste performante à condition que les lignes mises en
correspondance pour chaque valeur de l’index ne soient pas trop nombreuses.
fulltext : la jointure s’appuie sur un index plein texte.
 ref_or_null : comparable à ref, mais avec en plus une recherche
spécifique pour les lignes ayant une valeur NULL.
index_merge : ce type de jointure indique qu’une optimisation de type
merge est mise en œuvre. Celle-ci consiste à utiliser un ou plusieurs index sur
plusieurs plages de valeurs puis à fusionner les résultats en un seul.
unique_subquery : ce type se substitue à ref pour certaines sous-
requêtes dont le résultat est soumis à une clause IN. Dans ce cas, l’optimiseur,
quand il le peut, remplace la sous-requête par la recherche directe d’un index pour
plus d’efficacité. Cela se produit quand, par exemple, la sous-requête d’origine
renvoie comme résultat une liste de clés primaires.
index_subquery : comparable à unique_subquery, à
l’exception que le résultat de la sous-requête n’est pas une liste de clés primaires,
mais une liste d’index qui renvoient donc potentiellement plusieurs résultats pour
chaque valeur de l’index.
range : seules les lignes correspondant à un intervalle donné sont parcourues.
En complément, la colonne key indique quel index est utilisé. La valeur affichée
dans la colonne ref est toujours NULL dans ce cas.
index : identique au type ALL ci-après, si ce n’est que l’index est parcouru.
Cela se produit dans deux cas. 1) Les informations contenues dans l’index suffisent
à la requête et il n’est donc pas nécessaire de lire les données de la table. 2) Toutes
les données de la table sont lues, mais elles sont parcourues dans l’ordre de l’index,
afin par exemple de faire l’économie d’un deuxième tri commandé par un ORDER
BY.
ALL : toute la table est parcourue, c’est le cas le plus défavorable.

possible_keys Liste des index possibles.

key Parmi les index possibles, celui qui est choisi par l’optimiseur.

key_len Longueur en octets de la clé choisie.

ref Liste des colonnes comparées à l’index.

rows Estimation du nombre de lignes à examiner.

filtered Pourcentage des lignes de la table filtrées.

Extra Informations additionnelles.