As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Consulta em execução lenta
## Identificação - Identifique o problema
Uma consulta de execução lenta é aquela que excede o tempo de execução esperado para seus requisitos de negócios. A definição do que constitui uma consulta lenta varia entre diferentes cargas de trabalho. Você pode identificar consultas lentas por meio de registros do profiler ou Performance Insights.
1. Ative o profiler se ainda não estiver ativado. Os registros do Profiler são gravados na Amazon CloudWatch sob o Log Group:`/aws/docdb//profiler`. Use o CloudWatch Logs Insights para consultá-los.
**Exemplo** de consulta de análise de CloudWatch log para obter as 10 consultas mais lentas da coleção ecommerce.products:
```
filter ns="ecommerce.products" | sort millis desc | limit 10
```
1. Use o Performance Insights para identificar consultas caras quase em tempo real. Ative o Performance Insights se ele ainda não estiver ativado.
1. Abra o AWS console, navegue até Amazon Amazon DocumentDB, depois Performance Insights e selecione sua instância de cluster.
1. Analise o cronograma de carregamento de banco de dados (AAS) e as principais consultas (por carga de banco de dados). Expanda um resumo de consulta para ver declarações secundárias literais.
1. Capture as consultas que exigem análise.
**nota**
Nem todas as consultas no Performance Insights podem ser ineficientes ou lentas.
## Investigue — Reúna informações
1. O criador de perfil fornece o plano de execução da consulta e as principais métricas associadas a ele, incluindo millis, nreturned e planSummary (uso do índice):
```
{
"op": "query",
"ts": 1721374275673,
"ns": "test.perf",
"command": {
"find": "perf",
"filter": {
"threadRunCount": 0
},
"$db": "test",
"lsid": {
"id": {
"$binary": "oO2wEtpgQIK+y9KGByYnsw==",
"$type": "4"
}
},
"$readPreference": {
"mode": "secondaryPreferred"
}
},
"cursorExhausted": true,
"nreturned": 0,
"responseLength": 0,
"protocol": "op_query",
"millis": 137,
"planSummary": "IXSCAN",
"execStats": {
"stage": "FETCH",
"nReturned": "0",
"executionTimeMillisEstimate": "100.346",
"inputStage": {
"stage": "IXSCAN",
"nReturned": "0",
"executionTimeMillisEstimate": "100.342",
"indexName": "threadRunCount_1"
}
},
"client": "172.31.6.165:43154",
"appName": "ProdAppTester14",
"user": "adminuser"
}
```
Para encontrar as consultas do COLLSCAN:
```
filter planSummary="COLLSCAN" | sort millis desc | limit 20
```
1. Use o Performance Insights para analisar tendências de execução de consultas, como esperas, carga e impacto nos recursos (por exemplo, IOPS ou CPU por consulta) em tempo real.
Como o Performance Insights não fornece o plano de execução da consulta, capture a consulta e execute explain (“ExecutionStats”) na consulta em seu cluster Amazon DocumentDB:
```
db.ecommerce.products.find().explain("executionStats")
```
1. Opcionalmente, correlacione as métricas do profiler com os dados do Performance Insights (por exemplo, combine muitos milhões de consultas no Profiler com as principais consultas no Performance Insights).
## Diagnosticar — Encontre a causa raiz
Nesta etapa, diagnostique o plano de consulta para identificar possíveis otimizações. Use o seguinte fluxo - sintoma → causa provável:
+ **Sintoma: Resumo do plano:** “COLLSCAN”
**Causa:** Índice ausente ou incorreto.
+ **Sintoma:** agregação lenta com $group/$sort
**Causa:** o pipeline de agregação pode estar processando muitos dados na memória.
+ **Sintoma:** altas latências enquanto o Performance Insights mostra a carga de banco de dados agrupada por esperas de E/S, embora os índices sejam utilizados (PlanSummary: “IXSCAN”).
**Causa:** consultas I/O vinculadas; índices ou conjuntos de trabalho excedem o cache de buffer disponível na instância.
+ **Sintoma:** PI mostra estados de espera da CPU, alto AAS devido a poucas consultas
**Causa:** CPU-bound consultas (agregações complexas, $regex).
+ **Sintoma:** muitas consultas lentas, mas nenhuma mostra um plano caro. Resumo
**Causa:** gargalo externo (rede, limitação, tarefas de manutenção, volume de consultas).
## Resolver — Corrija o problema
Ao implementar correções, sempre valide com explain (“ExecutionStats”) e monitore a carga de banco de dados do Performance Insights.
1. **Resumo do plano: “COLLSCAN”**
+ Crie um índice direcionado.
**Exemplo:** Para consultas frequentes que filtram por {categoria, preço} e classificam por preço decrescente:
```
db.products.createIndex({ category: 1, price: -1 })
```
1. **agregação lenta com $group/$sort**
+ Pressione $match e $project com antecedência para reduzir o fluxo de documentos para $group/$sort.
+ Limite o número de campos no início do pipeline:
```
db.products.explain("executionStats").aggregate([
{ $match: { category: "Electronics", price: { $gt: 0 } } }, // early filter
{ $project: { price: 1, category: 1 } }, // reduce document size
{ $group: { _id: "$category", avgPrice: { $avg: "$price" } } }
])
```
1. **altas latências, enquanto o Performance Insights mostra a carga de banco de dados agrupada por esperas de E/S**
+ Valide se BufferCacheHitRatio está baixo ou se os ReadiOps na instância estão altos. Aumente a memória da instância (atualize a classe da instância, por exemplo, r6g.large → r6g.xlarge) ou use a classe de instância NVMe.
+ Reduza a pegada do índice.
+ Adicione réplicas de leitura para descarregar o tráfego de leitura (use a configuração ReadPreference para redirecionar o tráfego nas réplicas se a consulta for tolerante com uma eventual consistência).
1. **PI mostra estados de espera da CPU, alto AAS devido a poucas consultas**
+ Substitua o caro $regex por pesquisas de prefixo indexado ou índice $text.
+ Gravações em lote (inserção) para reduzir a amplificação de gravação.
**nota**
Sempre teste suas alterações em um ambiente inferior (sem produção) antes de promover essas alterações para a Produção.