EXPLAIN montre le plan choisi par l'optimiseur — comment il accédera à chaque table — sans exécuter la requête. Vous le lisez pour confirmer que les index sont utilisés et que peu de lignes sont examinées.
EXPLAIN montre le plan choisi par l'optimiseur — comment il accédera à chaque table — sans exécuter la requête. Vous le lisez pour confirmer que les index sont utilisés et que peu de lignes sont examinées.
const / eq_ref / ref (recherches par index, bien) → range → index (parcours complet de l'index) → ALL (full table scan, le signal d'alarme).NULL = aucun).Using index (couvrant, excellent), Using filesort / Using temporary (tri/regroupement en mémoire ou sur disque — souvent optimisable).EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- parcourt tout, trie
-- +------+------+------+---------+--------+----------------+
-- Ajoutez un index qui couvre le filtre ET l'ordre de tri :
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- recherche 30 lignes, pas de filesort
L'index a transformé un parcours ALL de 900k lignes en une recherche ref de 30, et comme created_at est la deuxième colonne, les lignes ressortent déjà triées — le filesort disparaît.
Utilisez EXPLAIN ANALYZE (MySQL 8) pour voir aussi les temps et nombres de lignes réels, ce qui permet de détecter les cas où l'estimation est fausse.
EXPLAIN est ce qui vous permet de remplacer les suppositions par des preuves. Repérer type: ALL, un rows énorme ou Using filesort vous indique exactement où il manque un index — le chemin le plus rapide entre "la page est lente" et un correctif ciblé.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don