Lorsque qu'une requête est lente, la pire réaction est d'optimiser par instinct.
PostgreSQL vous indique déjà comment il a exécuté la requête. Vous devez juste demander.
C'est à cela que sert EXPLAIN ANALYZE.
Commencez par le Plan, Pas par la Théorie
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE status = 'archived';
Cela vous donne le plan d'exécution réel, pas seulement le texte SQL que vous espériez être efficace.
Les Premières Choses à Examiner
Vous n'avez pas besoin de maîtriser chaque nœud de plan dès le premier jour. Commencez par :
- type de scan : scan séquentiel vs accès par index
- lignes estimées vs lignes réelles
- temps d'exécution total
- si des étapes coûteuses sont répétées plusieurs fois
Ces éléments suffisent souvent à expliquer la plupart des incidents "pourquoi cela est-il lent ?".
Un Scan Séquentiel N'est Pas Automatiquement Mauvais
Une des erreurs les plus courantes des débutants est de supposer que chaque Seq Scan est un bug.
Ce n’est pas le cas.
Si la table est petite ou si la requête nécessite déjà un pourcentage important des lignes, un scan séquentiel peut être le bon plan.
La vraie question est de savoir si le plan choisi correspond à la charge de travail.
Ce qu'un Index Change Souvent
Si un filtre sélectif manque d'un index utile, PostgreSQL peut ne pas avoir de moyen peu coûteux pour restreindre la recherche.
Ajouter un index peut changer cela :
CREATE INDEX idx_users_status ON users(status);
Mais même alors, ne vous arrêtez pas à "index ajouté". Exécutez à nouveau EXPLAIN ANALYZE et confirmez que le nouveau plan est réellement meilleur.
La Vraie Compétence
Lire les plans d'exécution concerne moins la mémorisation des noms de nœuds et plus le questionnement :
- combien de lignes PostgreSQL pensait-il toucher ?
- combien en a-t-il réellement touchées ?
- où le temps est-il perdu ?
- le plan effectue-t-il des travaux répétés ?
C'est le chemin du folklore à l'ingénierie.
Lectures Supplémentaires