tablestudioapp/plugins

Tornando consultas mais rápidas com o TableStudio

O TableStudio pode medir, não apenas adivinhar. Nunca recomende um índice ou uma reescrita por intuição quando você pode comprovar com as ferramentas abaixo. A maioria delas é exclusiva do PostgreSQL; em outros mecanismos, use explain_query e raciocine a partir do plano.

Escolha a conexão primeiro, conforme descrito no skill database-workflow. Prefira executar análises em um banco de dados com dados realistas. Um banco de dados de desenvolvimento quase vazio fornece planos enganosos.

Encontre o que está lento

• O usuário nomeia uma consulta ou um endpoint: encontre o SQL que ele executa (a partir do código ou do log do ORM), depois vá para "Diagnosticar uma instrução".
• "Por que o banco de dados está lento?" Chame slow_queries. Ele classifica as instruções por tempo total a partir de pg_stat_statements. Mantenha o query_id de cada linha; as outras ferramentas o aceitam. Se a extensão não estiver instalada, a ferramenta explica o que é necessário para ativá-la, então repasse essas informações em vez de instalá-la sem permissão.
• Ajuste amplo: workload_index_advisor encontra o menor número de índices que cobrem a maior parte do tempo do banco e lista índices existentes que nunca são usados.

Uma verificação de saúde

Quando o usuário pergunta o que há de errado com um banco de dados, ou quer uma revisão geral, não altere nada e relate:

1. database_health. Leia sua lista unavailable antes de resumir: uma lista de descobertas vazia com entradas lá significa que as verificações foram ignoradas, não que está tudo bem.
2. database_overview para tamanho, as maiores e mais movimentadas tabelas e contagens de conexões.
3. schema_issues (sem table) para problemas de design em todo o banco de dados.

Coloque as descobertas mais importantes primeiro, em linguagem simples: o que está errado, o que custa se ignorado e a correção. Inclua o verify_sql de cada descoberta para que o usuário possa verificar o número, e o lock_impact de qualquer correção. Ofereça-se para colocar as correções que o usuário escolher através de "Implementar" abaixo.

Diagnosticar uma instrução

1. optimize_query com o SQL (e query_id se veio de slow_queries). Para uma instrução somente leitura, passe analyze: true para que as verificações medidas possam ser executadas. Ele executa uma vez dentro de uma transação revertida. Ele relata already_fast quando não há nada que valha a pena fazer; informe isso em vez de inventar uma melhoria.
2. Para mais detalhes, use explain_query (analyze: true apenas para leituras). Compare actual_rows com estimated_rows em cada nó. Uma grande diferença significa estatísticas desatualizadas (faça ANALYZE na tabela), o que geralmente é o verdadeiro bug em vez de um índice faltante.
3. Uma instrução com placeholders $1, $2 precisa de valores reais para planejar com honestidade. suggest_parameter_values os encontra a partir do histórico, sessões ativas e estatísticas.

Comprove a correção

Use benchmark_query_variants (o Laboratório de Consultas) antes de recomendar qualquer coisa:

• Forneça o SQL de base e os candidatos como variants: um sql reescrito, hypothetical_indexes (planejados com hypopg, nunca construídos), hide_indexes ou configurações do planejador settings. Ou deixe variants de fora e deixe find_faster propor suas próprias.
• Ele relata medianas de várias execuções para cada conjunto de parâmetros e verifica se cada reescrita retorna as mesmas linhas que a base.
• Recomende apenas uma variante cujo same_rows seja sim. Prefira a variante em recommendation. Cite os valores medidos antes e depois, não porcentagens da intuição.

Antes de remover um índice (não usado ou duplicado), execute index_what_if com ele em hide. Qualquer instrução que fique mais cara, ou use o índice hoje, seria prejudicada.

Implementar

Índices e reescritas passam pelo fluxo normal de alteração do skill database-workflow:

• Alterações de índice são alterações de esquema. Se o repositório tiver uma ferramenta de migração, adicione o índice lá. Caso contrário, proponha-o com stage_migration, com os números medidos no rationale.
• No PostgreSQL, use CREATE INDEX CONCURRENTLY para qualquer tabela que receba tráfego e não a envolva em uma transação.
• Uma reescrita de consulta é uma alteração de código: edite o código que a emite e mencione o resultado do benchmark no seu resumo.