Lire la sortie de explain() pour diagnostiquer les requêtes

Les requêtes lentes dans MongoDB sont généralement dues à des index manquants ou à des plans de requête sous-optimaux. La méthode explain() révèle exactement ce que MongoDB a fait pour exécuter une requête : quel index a été choisi, combien de documents ont été analysés et combien de temps chaque étape a pris. Sans explain(), l’optimisation des performances repose sur des suppositions ; avec lui, vous obtenez un rapport de diagnostic précis.

Le mode explain() par défaut renvoie la sortie du planificateur de requêtes : le plan gagnant et les plans rejetés, mais sans exécuter réellement la requête. Ce mode est rapide et utile pour examiner rapidement la structure du plan. Le champ principal est winningPlan, qui décrit l’arborescence des étapes d’exécution que MongoDB utiliserait.

Les deux noms d’étape les plus importants dans la sortie de explain() sont : IXSCAN (analyse d’index) — la requête a utilisé un index ; et COLLSCAN (analyse de collection) — MongoDB a analysé chaque document. Un COLLSCAN sur une collection de production contenant des millions de documents est presque toujours un problème. La présence de COLLSCAN est le premier signe indiquant que vous devez ajouter ou améliorer un index.

explain('executionStats') exécute réellement la requête et recueille des données de durée. Les métriques les plus importantes sont : nReturned — les documents renvoyés au client ; totalDocsExamined — les documents examinés par MongoDB ; et totalKeysExamined — les entrées d’index analysées. Une requête efficace devrait avoir nReturned ≈ totalDocsExamined. Un écart important révèle un travail inutile.

Trois ratios vous indiquent l’efficacité d’une requête : clés examinées / clés renvoyées (un ratio faible est bon, 1:1 est idéal), documents examinés / documents renvoyés (devrait être proche de 1) et documents examinés / clés examinées (une valeur bien supérieure à 1 signifie que l’index filtre efficacement, mais que la récupération est coûteuse). Ces ratios vous aident à déterminer si vous avez besoin d’un meilleur index, d’une requête couverte ou d’une autre stratégie de filtrage.

Après qu’un IXSCAN a identifié les entrées d’index correspondantes, MongoDB peut devoir effectuer un FETCH des documents réels depuis le disque pour vérifier les conditions qui ne sont pas couvertes par l’index ou pour renvoyer des champs absents de l’index. Une requête couverte élimine entièrement l’étape FETCH. Si vous voyez IXSCAN → FETCH avec une valeur élevée de totalDocsExamined, envisagez d’ajouter les champs projetés à l’index afin de permettre la couverture.

MongoDB évalue en parallèle plusieurs plans candidats pendant une exécution d’essai et sélectionne le gagnant en fonction du nombre de documents que chaque plan renvoie par unité de travail. Le plan gagnant est mis en cache pour cette forme de requête, afin que les exécutions suivantes évitent une nouvelle évaluation. Vous pouvez afficher les plans rejetés avec le niveau de verbosité allPlansExecution. Le cache est invalidé lorsque les index changent ou que les statistiques de la collection sont mises à jour de manière importante.

Lorsque MongoDB ne peut pas utiliser un index pour satisfaire un tri, il ajoute au plan une étape SORT en mémoire. Les tris en mémoire sont limités à 100 MB par défaut ; au-delà, la requête échoue, sauf si vous activez allowDiskUse. La présence d’une étape SORT indique qu’il faut ajouter un index composé dont l’ordre des clés correspond à celui du tri, afin d’éliminer entièrement le tri en mémoire.

Le planificateur de requêtes de MongoDB choisit généralement le meilleur index, mais il sélectionne parfois un plan sous-optimal, notamment lorsque les statistiques sont obsolètes. Vous pouvez forcer l’utilisation d’un index précis avec .hint(), en transmettant soit le modèle de clés de l’index, soit son nom. C’est utile pour le débogage, afin de comparer les plans, ou en dernier recours en production lorsque le planificateur fait de mauvais choix.

Les pipelines d’agrégation prennent également en charge explain(). Transmettez { explain: true } à aggregate() pour voir comment les étapes du pipeline s’exécutent et si les premières étapes, comme $match, utilisent des index. L’idée essentielle est la suivante : un $match au début du pipeline peut transmettre un filtre à un IXSCAN ; un $match placé après un $group ne le peut pas.

Lorsque vous examinez la sortie de explain(), surveillez les signes d’alerte suivants : un COLLSCAN sur une grande collection ; une valeur de totalDocsExamined nettement supérieure à nReturned ; une étape SORT en mémoire ; ou une valeur de executionTimeMillis supérieure à votre SLA. Chacun de ces signes indique une correction précise : ajouter un index, modifier l’ordre des clés de l’index, ajouter les champs de tri à l’index composé ou repenser la requête.

Dans cette leçon, vous avez appris que explain('executionStats') exécute la requête et fournit sa durée ainsi que le nombre de documents, que COLLSCAN ou IXSCAN dans le plan gagnant indique immédiatement si un index a été utilisé et que le ratio nReturned / totalDocsExamined mesure l’efficacité de l’index. Nous allons maintenant découvrir les index textuels pour la recherche en texte intégral.