Query Regressions

Por que o DBA precisa de Query Regressions

O que ele faz

• Fingerprint estável estilo sql_id por shape de query — queryHash nativo no MongoDB, shape-hash client-side no Cosmos/DocumentDB — então a query mantém uma identidade só mesmo com valores diferentes.
• Cross-engine por design: MongoDB / Atlas, Azure Cosmos DB (Mongo API) e AWS DocumentDB — a única ferramenta que dá RCA de regressão nos três.
• Captura ao vivo instance-wide: vê as queries de TODOS os clientes, então pega a mudança não-declarada feita numa janela de manutenção — não só as queries que você roda.
• Causa-raiz em 5 níveis: (1) métricas antes/depois, (2) diff do plano de execução, (3) sondas de índice / cardinalidade, (4) eventos de DDL & deploy correlacionados em ±5 min, (5) narrativa de IA com o seu próprio LLM.
• Classifica a causa: mudança de plano, colapso de seletividade, crescimento de dados, pico de RU, ou um collection scan lento nunca visto.
• Métrica por engine: latência p95 no MongoDB / DocumentDB, RU no Cosmos.
• Monitoramento dirigido pelo DBA: você arma na tela (instância inteira ou bancos escolhidos, com agendamento opcional); roda como job no Job Manager com bolinha de gravação ao vivo — sua máquina não é um servidor.
• Alerta em regressões confirmadas: notificação nativa do SO + webhook (Slack, Discord e Microsoft Teams auto-detectados pela URL), com intervalo de re-alerta que você define em segundos.
• Tudo persiste: baselines aprendidos e o histórico de alertas sobrevivem a restart (arquivo + mirror MongoDB), então uma regressão pega de madrugada continua lá de manhã — filtra por período, marca lido/não-lido, exclui.
• Remediação em um clique: limpa o plan cache numa mudança de plano, reconhece, adia (snooze), ou abre o explain plan.

Passo a passo

1. 1

   Abra Monitoring ▾ → Query Regressions

   A aba abre com os alertas que já dispararam para esta conexão, agrupados por banco. Nada a configurar para ver o histórico.

2. 2

   Arme o monitoramento no escopo que importa

   Clique Start e escolha a instância inteira ou bancos específicos, opcionalmente com agendamento início/fim. Registra como job no Job Manager e segue rodando independente da aba.

3. 3

   Exemplo — uma "new slow query"

   Um collection scan nunca-visto sobre muitos docs é sinalizado na hora, sem precisar de baseline. Filtro em campo sem índice é o caso clássico:

   // campo sem índice -> COLLSCAN na coleção inteira
   db.orders.find({ promoCode: "BLACKFRIDAY" })
   
   // → card: New slow query — shop.orders
   //   plano: COLLSCAN  ·  docs examinados 1.550.000  ·  p95 642 ms  ·  WARN

4. 4

   Exemplo — uma regressão de baseline

   Uma query que era barata contra o baseline aprendido passa a custar muito mais. Mesmo fingerprint, só o plano/custo mudou — ex.: um índice foi derrubado e o IXSCAN virou COLLSCAN:

   // mesma query, mesmo fingerprint — só o plano mudou
   baseline (35 amostras):  IXSCAN { userId:1, status:1 }   p95   2.5 ms
   agora:                   COLLSCAN                        p95 185.0 ms
   
   // → card: Plan regression — shop.orders
   //   delta 74x  ·  causa: plan-change  ·  CRITICAL
   //   o que mudou perto: dropIndex idx_user_status (2 min antes)

5. 5

   Leia o card + rode a causa-raiz por IA (Nível 5)

   Severidade, o fingerprint, Baseline → Agora para latência e docs examinados, o diff do plano, o shape da query e o que mudou por perto. Aí rode a análise Nível 5 com o seu LLM — ela lê só o fact sheet e termina com a causa mais provável + um score de confiança.

6. 6

   Corrija, e seja alertado na próxima

   Limpe o plan cache ou crie o índice; configure o alerta SO + Slack/Discord/Teams uma vez em Settings ▸ Alerting para a próxima regressão te alcançar onde você estiver.

Casos de uso reais

FAQ