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 conexplain("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
docsExaminednon 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).
