Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Analisi del piano di interrogazione
L'analisi del piano di query tramite explain plan fornisce informazioni essenziali sulle prestazioni delle query di Amazon DocumentDB. Il piano di query con ExecutionStats rivela metriche chiave, tra cui:
+ Documenti restituiti per fase (nReturned)
+ Stage-specific tempi di esecuzione (esecuzioneTimeMillisEstimate)
+ Durata della generazione del piano (pianificazioneTimeMillis)
Esaminando l'output del piano di query, gli sviluppatori possono analizzare i modelli di esecuzione, valutare l'utilizzo degli indici e identificare potenziali opportunità di ottimizzazione nelle fasi della pipeline di query.
Per analizzare il piano di interrogazione, è possibile utilizzare il comando explain () nei seguenti formati.
```
db.runCommand({explain: {query document}, verbosity: "executionStats"})
db.collection.find().explain("executionStats");
```
Di seguito è riportato un esempio di operazione:
```
db.collection.find({ companyname: { '$eq': 'ANYCOMPANY' }, isDeleted: { '$eq': false } }).sort({"createdAt":1}).limit(2).explain("executionStats");
```
L'aspetto dell'output di questa operazione è simile al seguente.
```
{
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 })
}
```
Di seguito è riportata un'analisi dettagliata di un piano di esecuzione delle query di Amazon DocumentDB, che analizza ogni componente e le sue caratteristiche prestazionali.
## Tempistica complessiva
l'esecuzione TimeMillis rappresenta il tempo totale impiegato dalla query, incluso il tempo di pianificazione.
la pianificazione TimeMillis rappresenta il tempo totale di pianificazione impiegato dall'interrogazione.
## Fasi di esecuzione
Descrive il processo dettagliato utilizzato da Amazon DocumentDB per eseguire una query, mostrando come i dati fluiscono attraverso diverse operazioni.
```
"executionStages": {
"stage": "[STAGE_NAME]",
"nReturned": "[NUMBER_OF_DOCS]",
"executionTimeMillisEstimate": "[TIME]",
"inputStage": {
// Nested stages
}
}
```
### Fasi comuni di un piano di query
Di seguito sono riportate le fasi di esecuzione più comuni in un piano di interrogazione. Ogni fase restituisce le metriche di esecuzione TimeMillisEstimate (tempo di esecuzione) e nReturned (numero di documenti) per aiutare a valutare le prestazioni delle query in ogni fase.
#### COLLSCAN (scansione della raccolta)
+ Scansiona l'intera collezione documento per documento
+ nReturned: restituisce tutti i documenti corrispondenti nella raccolta
+ Può essere un'operazione costosa, vista quando non è disponibile alcun indice
#### IXSCAN (scansione dell'indice)
+ Utilizza un indice per trovare i documenti corrispondenti
+ nRestituito: solo i documenti corrispondenti in base all'indice
+ Funzionamento efficiente, preferito rispetto a COLLSCAN
#### SORT
+ Ordina i documenti in base a campi specifici
+ Se l'attributo sort nella query non fa parte di un indice, questa fase verrà visualizzata in modo esplicito
+ nRestituito: stesso numero dei documenti di input
+ Memory-intensive per set di risultati di grandi dimensioni. Per ottimizzare, aggiungi il nome del campo di ordinamento a un indice
#### LIMIT\_SKIP
+ Controlla il numero di documenti restituiti e ignorati
+ nRestituito: limitato dal valore LIMIT
+ Utilizzato per operazioni di impaginazione o LIMIT
#### SOTTOSCANSIONE
+ Esegue operazioni di interrogazione annidate
+ nReturned: varia in base ai risultati delle subquery
+ Utilizzato in interrogazioni complesse con più fasi
Gli stadi ad alta esecuzione TimeMillisEstimate sono buoni candidati per l'ottimizzazione.
**Nota**
Il parametro ExecutionStats attualmente non supporta i comandi di aggiornamento ed eliminazione.
## Comprensione dei documenti esaminati in Explain Plan Execution Stats
Quando esegui una query con`explain("executionStats")`, Amazon DocumentDB fornisce parametri di esame che ti aiutano a capire quanti documenti sono stati scansionati per produrre i risultati della query. Queste metriche sono utili per identificare piani di query inefficienti e ottimizzare le prestazioni.
**Nota**
Disponibile solo in Amazon DocumentDB 8.0.0\+.
### Campi
| Campo | Description | Livello |
| --- | --- | --- |
| totale DocsExamined | Numero totale di documenti esaminati in tutte le fasi di esecuzione. | Top-level ExecutionStats |
| Documenti esaminati | Numero di documenti esaminati in una fase di esecuzione specifica. | Stage-level |
Il `docsExamined` campo viene visualizzato nelle seguenti fasi:
| Stage | Description |
| --- | --- |
| COLLSCAN | Scansione della collezione. Tutti i documenti della collezione vengono esaminati. |
| È UNA SCANSIONE | Scansione dell'indice. Vengono esaminati solo i documenti che corrispondono alla condizione dell'indice. |
| FETCH | Quando l'ottimizzatore recupera i documenti in una fase separata da IXSCAN, la fase FETCH riporta DocExamined. Nei piani di scansione degli indici, gli stadi IXSCAN secondari non riportano DocExamined. Nei piani $lookup, sia la fase FETCH che le relative fasi secondarie possono riportare DOCExamined. |
**Nota**
`docsExamined`non viene visualizzato nelle fasi IXONLYSCAN perché la query viene soddisfatta interamente dall'indice senza accedere ai documenti.
### Mostra DocExamined nell'output Explain Plan ExecutionStats
Gli esempi seguenti utilizzano una raccolta con 500.000 documenti e dimostrano come `docsExamined` cambia nelle diverse fasi di esecuzione delle query.
Crea dati di esempio:
```
for (let i = 0; i < 500000; i++) {
db.coll.insertOne({ number: i, arr: [i, [i+1]], value: "test", bool: i % 2 === 0 });
}
```
#### Scansione della raccolta (COLLSCAN)
Senza un indice, Amazon DocumentDB esegue una scansione completa della raccolta.
```
db.coll.find({ "number": { "$lt": 500 } }).explain("executionStats").executionStats
```
Output:
```
{
"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
}
}
}
}
```
Tutti i 500.000 documenti sono stati esaminati per restituire 500 risultati. La creazione di un indice nel campo numerico migliora questa situazione.
#### Scansione dell'indice (IXSCAN)
```
db.coll.createIndex({ number: 1 });
db.coll.find({ "number": { "$lt": 5000 } }).explain("executionStats").executionStats
```
Output:
```
{
"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
}
}
]
}
}
}
```
Con l'indice, solo 5.000 documenti su 500.000 sono stati esaminati e recuperati, corrispondenti al numero restituito. La condizione dell'indice ha filtrato 495.000 documenti che non corrispondevano alla query.
#### Scansione dell'indice con filtro residuo
```
db.coll.find({ "number": { "$lt": 5000 }, "arr": { "$gt": 4000 } }).explain("executionStats").executionStats
```
Output:
```
{
"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 condizione dell'indice corrispondeva a 5.000 documenti su 500.000, quindi il filtro residuo attivo ha `arr` ridotto il risultato a 999. Il `docsExamined` valore di 5.000 riflette tutti i documenti esaminati dopo la condizione dell'indice ma prima dell'applicazione del filtro residuo.
#### Effettua il recupero con IXSCAN
```
db.coll.find({ "$or": [{ "number": { "$lt": 100000 } }, { "number": { "$gt": 400000 } }] }).explain("executionStats").executionStats
```
Output:
```
{
"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
}
}
]
}
}
]
}
}
}
```
Quando Amazon DocumentDB Optimizer utilizza una fase di recupero per recuperare i documenti, la fase FETCH riporta i risultati. `docsExamined` Le fasi secondarie IXSCAN non generano report `docsExamined` perché scansionano solo le chiavi dell'indice senza accedere direttamente ai documenti.
#### FETCH con Aggregate Lookup
```
db.coll.explain("executionStats").aggregate([
{ $match: { "number": { "$lt": 5 } } },
{ $lookup: { from: "coll", pipeline: [{ $match: { "number": { "$lt": 3 } } }], as: "sub" } }
]).executionStats
```
Output:
```
{
"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 esterno ha esaminato 5 documenti corrispondenti a un numero < 5. L'IXSCAN interno ha esaminato 3 documenti corrispondenti al numero < 3 e la fase FETCH ha esaminato 1 risultato aggregato. Il numero `totalDocsExamined` di 9 è la somma di tutti gli stadi (5 \+ 3 \+ 1).