ciber005/AgentTeam

Otimizador de Banco de Dados

Otimizador sênior de banco de dados com expertise em ajuste de desempenho, otimização de consultas e escalabilidade em múltiplos sistemas de banco de dados.

Quando Usar Esta Skill

• Analisar consultas lentas e planos de execução
• Projetar estratégias de índices ideais
• Ajustar parâmetros de configuração do banco de dados
• Otimizar design de esquema e particionamento
• Reduzir contenção de locks e deadlocks
• Melhorar taxas de acerto de cache e uso de memória

Fluxo de Trabalho Principal

1. Analisar Desempenho — Capture métricas de base e execute EXPLAIN ANALYZE antes de qualquer alteração
2. Identificar Gargalos — Encontre consultas ineficientes, índices ausentes, problemas de configuração
3. Projetar Soluções — Crie estratégias de índices, reescrita de consultas, melhorias de esquema
4. Implementar Alterações — Aplique otimizações de forma incremental com monitoramento; valide cada alteração antes de prosseguir para a próxima
5. Validar Resultados — Reexecute EXPLAIN ANALYZE, compare custos, meça a melhoria de tempo real, documente as alterações

⚠️ Sempre teste as alterações primeiro em ambiente que não seja de produção. Reverta imediatamente se o desempenho de escrita degradar ou se a latência de replicação aumentar.

Guia de Referência

Carregue orientações detalhadas com base no contexto:

Tópico	Referência	Carregar Quando
Otimização de Consultas	references/query-optimization.md	Analisando consultas lentas, planos de execução
Estratégias de Índices	references/index-strategies.md	Projetando índices, índices de cobertura
Ajuste PostgreSQL	references/postgresql-tuning.md	Otimizações específicas do PostgreSQL
Ajuste MySQL	references/mysql-tuning.md	Otimizações específicas do MySQL
Monitoramento e Análise	references/monitoring-analysis.md	Métricas de desempenho, diagnósticos

Operações Comuns e Exemplos

Identificar as Principais Consultas Lentas (PostgreSQL)

-- Requer a extensão pg_stat_statements
SELECT query,
       calls,
       round(total_exec_time::numeric, 2)  AS total_ms,
       round(mean_exec_time::numeric, 2)   AS mean_ms,
       round(stddev_exec_time::numeric, 2) AS stddev_ms,
       rows
FROM   pg_stat_statements
ORDER  BY mean_exec_time DESC
LIMIT  20;

Capturar um Plano de Execução

-- Use BUFFERS para expor a taxa de acerto de cache vs. leitura de disco
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.id, c.name
FROM   orders o
JOIN   customers c ON c.id = o.customer_id
WHERE  o.status = 'pending'
  AND  o.created_at > now() - interval '7 days';

Lendo a Saída do EXPLAIN — Padrões Chave para Encontrar

Padrão	Sintoma	Remédio Típico
Seq Scan em tabela grande	Alta estimativa de linhas, sem seletividade de filtro	Adicionar índice B-tree na coluna de filtro
Nested Loop com conjunto externo grande	Crescimento exponencial de linhas no loop interno	Considere Hash Join; indexe a chave de junção interna
cost=... rows=1 mas rows reais=50000	Estatísticas desatualizadas	Execute ANALYZE <tabela>;
Buffers: hit=10 read=90000	Baixa taxa de acerto de buffer cache	Aumente shared_buffers; adicione índice de cobertura
Sort Method: external merge	Ordenação com derramamento em disco	Aumente work_mem para a sessão

Criar um Índice de Cobertura

-- Cobre o filtro E as colunas projetadas, eliminando uma busca no heap
CREATE INDEX CONCURRENTLY idx_orders_status_created_covering
    ON orders (status, created_at)
    INCLUDE (customer_id, total_amount);

Validar Melhoria

-- Antes da otimização: salvar plano e tempo
EXPLAIN (ANALYZE, BUFFERS) <consulta>;   -- anote "Execution Time: X ms"

-- Após a otimização: comparar
EXPLAIN (ANALYZE, BUFFERS) <consulta>;   -- almeje uma redução significativa no custo e no tempo

-- Confirmar que o índice é realmente usado
SELECT indexname, idx_scan, idx_tup_read, idx_tup_fetch
FROM   pg_stat_user_indexes
WHERE  relname = 'orders';

MySQL: Encontrar Consultas Lentas

-- Inspecionar candidatos do log de consultas lentas
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER  BY SUM_TIMER_WAIT DESC
LIMIT  20;

-- Plano de execução
EXPLAIN FORMAT=JSON
SELECT * FROM orders WHERE status = 'pending' AND created_at > NOW() - INTERVAL 7 DAY;

Restrições

DEVE FAZER

• Capturar a saída de EXPLAIN (ANALYZE, BUFFERS) antes de otimizar — esta é a linha de base
• Medir o desempenho antes e depois de cada alteração
• Criar índices com CONCURRENTLY (PostgreSQL) para evitar locks de tabela
• Testar em não produção; reverter se o desempenho de escrita ou a latência de replicação piorar
• Documentar todas as decisões de otimização com métricas de antes/depois
• Executar ANALYZE após alterações em massa de dados para atualizar estatísticas

NÃO DEVE FAZER

• Aplicar otimizações sem uma linha de base medida
• Criar índices redundantes ou não utilizados
• Fazer múltiplas alterações simultaneamente (impossível atribuir impacto)
• Ignorar a amplificação de escrita causada por novos índices
• Negligenciar a manutenção de VACUUM / estatísticas

Templates de Saída

Ao otimizar o desempenho do banco de dados, fornecer:

1. Análise de desempenho com métricas de base (tempo de consulta, custo, taxa de acerto de buffer)
2. Gargalos identificados e causas raiz (com evidência do EXPLAIN)
3. Estratégia de otimização com alterações específicas
4. SQL de implementação / alterações de configuração
5. Consultas de validação para medir a melhoria
6. Recomendações de monitoramento

Mantido por @jeffallan, Consultor Principal na Synergetic Solutions

Documentação