Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Analyse du plan de requêtes
L'analyse du plan de requête via le plan d'explication fournit des informations essentielles sur les performances des requêtes Amazon DocumentDB. Le plan de requête avec ExecutionStats révèle des indicateurs clés, notamment :
+ Documents renvoyés par étape (nReturned)
+ Stage-specific délais d'exécution (exécutionTimeMillisEstimate)
+ Durée de génération du plan (planificationTimeMillis)
En examinant le résultat du plan de requête, les développeurs peuvent analyser les modèles d'exécution, évaluer l'utilisation des index et identifier les opportunités d'optimisation potentielles au cours des étapes du pipeline de requêtes.
Pour analyser le plan de requête, vous pouvez utiliser la commande explain () dans les formats suivants.
```
db.runCommand({explain: {query document}, verbosity: "executionStats"})
db.collection.find().explain("executionStats");
```
Voici un exemple d'opération :
```
db.collection.find({ companyname: { '$eq': 'ANYCOMPANY' }, isDeleted: { '$eq': false } }).sort({"createdAt":1}).limit(2).explain("executionStats");
```
Le résultat de cette opération ressemble à ce qui suit :
```
{
queryPlanner: {
plannerVersion: 2,
namespace: 'limit_test.test',
winningPlan: {
stage: 'LIMIT_SKIP',
inputStage: {
stage: 'SORT',
sortPattern: { createdAt: 1 },
inputStage: {
stage: 'IXSCAN',
indexName: 'companyname_1_createdAt_1_isDeleted_1',
direction: 'forward',
indexCond: {
'$and': [
{ companyname: { '$eq': 'ANYCOMPANY' } },
{ isDeleted: { '$eq': false } }
]
}
}
}
}
},
indexFilterSet: false,
indexFilterApplied: false,
executionStats: {
executionSuccess: true,
executionTimeMillis: '4.186',
planningTimeMillis: '3.909',
executionStages: {
stage: 'LIMIT_SKIP',
nReturned: '2',
executionTimeMillisEstimate: '0.199',
inputStage: {
stage: 'SORT',
nReturned: '2',
executionTimeMillisEstimate: '0.197',
sortPattern: { createdAt: 1 },
inputStage: {
stage: 'IXSCAN',
nReturned: '34',
executionTimeMillisEstimate: '0.151',
indexName: 'companyname_1_createdAt_1_isDeleted_1',
direction: 'forward',
indexCond: {
'$and': [
{ companyname: { '$eq': 'ANYCOMPANY' } },
{ isDeleted: { '$eq': false } }
]
}
}
}
}
},
serverInfo: { host: 'demo-cluster', port: 27017, version: '5.0.0' },
ok: 1,
operationTime: Timestamp({ t: 1759915116, i: 1 })
}
```
Vous trouverez ci-dessous une analyse détaillée d'un plan d'exécution de requêtes Amazon DocumentDB, détaillant chaque composant et ses caractéristiques de performance.
## Chronométrage global
l'exécution TimeMillis représente le temps total nécessaire à la requête, y compris le temps de planification.
la planification TimeMillis représente le temps de planification total nécessaire à la requête.
## Étapes d'exécution
Il décrit le processus étape par étape qu'Amazon DocumentDB utilise pour exécuter une requête, en montrant comment les données circulent au cours des différentes opérations.
```
"executionStages": {
"stage": "[STAGE_NAME]",
"nReturned": "[NUMBER_OF_DOCS]",
"executionTimeMillisEstimate": "[TIME]",
"inputStage": {
// Nested stages
}
}
```
### Étapes courantes d'un plan de requête
Vous trouverez ci-dessous les étapes d'exécution courantes d'un plan de requête. Chaque étape renvoie des métriques d'exécution TimeMillisEstimate (temps d'exécution) et NReturned (nombre de documents) pour aider à évaluer les performances des requêtes à chaque étape.
#### COLLSCAN (numérisation des collections)
+ Numérise l'intégralité de la collection document par document
+ nReturned : renvoie tous les documents correspondants de la collection
+ Cela peut être une opération coûteuse, vu lorsqu'aucun indice n'est disponible
#### IXSCAN (analyse d'index)
+ Utilise un index pour trouver les documents correspondants
+ nReturned : seuls les documents correspondants sont basés sur l'index
+ Fonctionnement efficace, préféré à COLLSCAN
#### SORT
+ Trie les documents en fonction de champs spécifiés
+ Si l'attribut de tri de la requête ne fait pas partie d'un index, cette étape apparaîtra explicitement
+ nRetourné : même numéro que les documents d'entrée
+ Memory-intensive pour de grands ensembles de résultats. Pour optimiser, ajoutez le nom du champ de tri à un index
#### LIMIT\_SKIP
+ Contrôle le nombre de documents renvoyés et ignorés
+ nRetourné : limité par la valeur LIMITE
+ Utilisé pour les opérations de pagination ou de LIMIT
#### SOUS-SCAN
+ Effectue des opérations de requête imbriquées
+ nReturned : varie en fonction des résultats de la sous-requête
+ Utilisé dans les requêtes complexes comportant plusieurs étapes
Les étapes à haut niveau d'exécution TimeMillisEstimate sont de bons candidats à l'optimisation.
**Note**
Le paramètre ExecutionStats ne prend actuellement pas en charge les commandes de mise à jour et de suppression.
## Comprendre les documents examinés dans Explain Plan Execution Stats
Lorsque vous exécutez une requête avec`explain("executionStats")`, Amazon DocumentDB fournit des métriques d'examen qui vous aident à comprendre combien de documents ont été scannés pour produire les résultats de la requête. Ces mesures sont utiles pour identifier les plans de requêtes inefficaces et optimiser les performances.
**Note**
Disponible uniquement dans Amazon DocumentDB 8.0.0\+.
### Champs
| Champ | Description | Niveau |
| --- | --- | --- |
| total DocsExamined | Nombre total de documents examinés à toutes les étapes d'exécution. | Top-level ExecutionStats |
| Docs examinés | Nombre de documents examinés par une étape d'exécution spécifique. | Stage-level |
Le `docsExamined` champ apparaît aux étapes suivantes :
| Étape | Description |
| --- | --- |
| COLLISCAN | Numérisation de la collection. Tous les documents de la collection sont examinés. |
| IXSCAN | Scan de l'index. Seuls les documents correspondant à la condition d'index sont examinés. |
| FETCH | Lorsque l'optimiseur extrait des documents dans une étape distincte d'IXSCAN, l'étape FETCH indique DocsExamined. Dans les plans d'analyse d'index, les étapes IXSCAN secondaires ne signalent pas DocsExamined. Dans les plans $lookup, l'étape FETCH et ses étapes secondaires peuvent signaler DocsExamined. |
**Note**
`docsExamined`n'apparaît pas sur les stages IXONLYSCAN car la requête est entièrement satisfaite à partir de l'index sans accès aux documents.
### Afficher les documents examinés dans la sortie Explain Plan ExecutionStats
Les exemples suivants utilisent une collection de 500 000 documents et montrent comment cela `docsExamined` change au cours des différentes étapes d'exécution des requêtes.
Créez des exemples de données :
```
for (let i = 0; i < 500000; i++) {
db.coll.insertOne({ number: i, arr: [i, [i+1]], value: "test", bool: i % 2 === 0 });
}
```
#### Numérisation de la collection (COLLSCAN)
Sans index, Amazon DocumentDB effectue une analyse complète de la collection.
```
db.coll.find({ "number": { "$lt": 500 } }).explain("executionStats").executionStats
```
Sortie :
```
{
"executionSuccess" : true,
"nReturned" : "500",
"executionTimeMillis" : "282.055",
"planningTimeMillis" : "0.085",
"totalDocsExamined" : "500000",
"executionStages" : {
"stage" : "COLLSCAN",
"nReturned" : "500",
"executionTimeMillisEstimate" : "281.915",
"docsExamined" : "500000",
"filter" : {
"number" : {
"$lt" : 500
}
}
}
}
```
Les 500 000 documents ont tous été examinés pour obtenir 500 résultats. La création d'un index sur le champ numérique améliore cela.
#### Scan d'index (IXSCAN)
```
db.coll.createIndex({ number: 1 });
db.coll.find({ "number": { "$lt": 5000 } }).explain("executionStats").executionStats
```
Sortie :
```
{
"executionSuccess" : true,
"nReturned" : "5000",
"executionTimeMillis" : "3.047",
"planningTimeMillis" : "0.296",
"totalDocsExamined" : "5000",
"executionStages" : {
"stage" : "IXSCAN",
"nReturned" : "5000",
"executionTimeMillisEstimate" : "2.576",
"indexName" : "number_1",
"direction" : "forward",
"docsExamined" : "5000",
"indexCond" : {
"$and" : [
{
"number" : {
"$lt" : 5000
}
}
]
}
}
}
```
Grâce à cet index, seuls 5 000 documents sur 500 000 ont été examinés et récupérés, ce qui correspond au nombre de documents renvoyés. La condition d'index a filtré 495 000 documents qui ne correspondaient pas à la requête.
#### Scan d'index avec filtre résiduel
```
db.coll.find({ "number": { "$lt": 5000 }, "arr": { "$gt": 4000 } }).explain("executionStats").executionStats
```
Sortie :
```
{
"executionSuccess" : true,
"nReturned" : "999",
"executionTimeMillis" : "15.367",
"planningTimeMillis" : "0.115",
"totalDocsExamined" : "5000",
"executionStages" : {
"stage" : "IXSCAN",
"nReturned" : "999",
"executionTimeMillisEstimate" : "15.170",
"indexName" : "number_1",
"direction" : "forward",
"docsExamined" : "5000",
"indexCond" : {
"$and" : [
{
"number" : {
"$lt" : 5000
}
}
]
},
"filter" : {
"arr" : {
"$gt" : 4000
}
}
}
}
```
La condition d'index correspondait à 5 000 documents sur 500 000, puis le filtre résiduel activé `arr` a réduit le résultat à 999. La `docsExamined` valeur de 5 000 reflète tous les documents examinés après la condition d'indice mais avant l'application du filtre résiduel.
#### Récupérez avec IXSCAN
```
db.coll.find({ "$or": [{ "number": { "$lt": 100000 } }, { "number": { "$gt": 400000 } }] }).explain("executionStats").executionStats
```
Sortie :
```
{
"executionSuccess" : true,
"nReturned" : "199999",
"executionTimeMillis" : "899.801",
"planningTimeMillis" : "0.183",
"totalDocsExamined" : "199999",
"executionStages" : {
"stage" : "FETCH",
"nReturned" : "199999",
"executionTimeMillisEstimate" : "894.141",
"docsExamined" : "199999",
"inputStage" : {
"stage" : "IXOR",
"nReturned" : "0",
"executionTimeMillisEstimate" : "874.897",
"inputStages" : [
{
"stage" : "IXSCAN",
"nReturned" : "100000",
"executionTimeMillisEstimate" : "462.208",
"indexName" : "number_1",
"indexCond" : {
"$and" : [
{
"number" : {
"$lt" : 100000
}
}
]
}
},
{
"stage" : "IXSCAN",
"nReturned" : "99999",
"executionTimeMillisEstimate" : "412.684",
"indexName" : "number_1",
"indexCond" : {
"$and" : [
{
"number" : {
"$gt" : 400000
}
}
]
}
}
]
}
}
}
```
Lorsque l'optimiseur Amazon DocumentDB utilise une phase de récupération pour récupérer des documents, l'étape FETCH génère des rapports. `docsExamined` Les étapes IXSCAN secondaires ne produisent aucun rapport `docsExamined` car elles ne font que scanner les clés d'index sans accéder directement aux documents.
#### FETCH avec recherche agrégée
```
db.coll.explain("executionStats").aggregate([
{ $match: { "number": { "$lt": 5 } } },
{ $lookup: { from: "coll", pipeline: [{ $match: { "number": { "$lt": 3 } } }], as: "sub" } }
]).executionStats
```
Sortie :
```
{
"executionSuccess" : true,
"nReturned" : "5",
"executionTimeMillis" : "0.525",
"planningTimeMillis" : "0.327",
"totalDocsExamined" : "9",
"executionStages" : {
"stage" : "NESTED_LOOP_LOOKUP",
"nReturned" : "5",
"executionTimeMillisEstimate" : "0.163",
"inputStages" : [
{
"stage" : "IXSCAN",
"nReturned" : "5",
"executionTimeMillisEstimate" : "0.039",
"indexName" : "number_1",
"direction" : "forward",
"docsExamined" : "5",
"indexCond" : {
"$and" : [
{
"number" : {
"$lt" : 5
}
}
]
}
},
{
"stage" : "FETCH",
"nReturned" : "1",
"executionTimeMillisEstimate" : "0.009",
"docsExamined" : "1",
"inputStage" : {
"stage" : "AGGREGATE",
"nReturned" : "1",
"executionTimeMillisEstimate" : "0.044",
"inputStage" : {
"stage" : "IXSCAN",
"nReturned" : "3",
"executionTimeMillisEstimate" : "0.013",
"indexName" : "number_1",
"direction" : "forward",
"docsExamined" : "3",
"indexCond" : {
"$and" : [
{
"number" : {
"$lt" : 3
}
}
]
}
}
}
}
]
}
}
```
L'IXSCAN externe a examiné 5 documents dont le numéro était inférieur à 5. L'IXSCAN interne a examiné 3 documents correspondant à un nombre inférieur à 3, et l'étape FETCH a examiné 1 résultat agrégé. Le `totalDocsExamined` 9 est la somme de toutes les étapes (5 \+ 3 \+ 1).