Inspecionar um plano de consulta com estatísticas reais de execução (explain executionStats)
MongoDBDesempenhoComando
db.musteri.find({ sehir: "Ankara", durum: "aktif" }).sort({ kayitTarihi: -1 }).explain("executionStats")
// Summary: winning plan, returned documents, examined keys/documents and time
const e = db.musteri.find({ sehir: "Ankara", durum: "aktif" }).sort({ kayitTarihi: -1 }).explain("executionStats");
({ plan: e.queryPlanner.winningPlan, n: e.executionStats.nReturned, keys: e.executionStats.totalKeysExamined, docs: e.executionStats.totalDocsExamined, ms: e.executionStats.executionTimeMillis })
// For an aggregation:
db.musteri.explain("executionStats").aggregate([{ $match: { sehir: "Ankara" } }, { $group: { _id: "$durum", n: { $sum: 1 } } }])O que faz
Executa a consulta e mostra o plano vencedor (IXSCAN/COLLSCAN, estágio SORT), o número de documentos retornados, as chaves de índice e os documentos examinados e o tempo gasto.
Quando usar
Ao analisar uma consulta que aparece como lenta no profiler ou no log, e ao verificar se um novo índice é realmente usado.
Atenção
executionStats realmente executa a consulta; fazer explain de uma consulta pesada no horário de pico também adiciona carga. Para comandos de escrita (update/delete/findAndModify), o explain não modifica dados, mas executa o plano. Uma razão totalDocsExamined/nReturned alta ou um estágio SORT em memória no plano indica que o índice não é adequado.
Relacionados
- Extrair as consultas e query shapes mais lentas dos dados do profiler
- Encontrar índices não utilizados e ocultá-los antes de remover (hideIndex)
- Contar conexões por aplicação e cliente (diagnóstico de connection storm)
- Medir a pressão no cache do WiredTiger (ocupação, taxa de dirty, eviction pela aplicação)