AIDBA

O AIDBA é um copiloto de IA para quem administra banco de dados. Você cola um plano de execução, um log de lock ou uma migration. Ele devolve leitura técnica em português: onde a query gasta tempo, qual índice falta e o que muda se você mexer nisso.

DBA, backend e time de dados que sustentam PostgreSQL, MySQL, Oracle ou SQL Server em produção. O problema que ele resolve é o de sempre: a query degradou, o chamado é urgente e o material bom sobre plano de execução está todo em inglês, espalhado em blog velho e thread de Stack Overflow.

Leia de dentro para fora, do nó mais interno até o topo. Compare rows estimado com rows real: divergência grande costuma indicar estatística velha. Olhe actual time acumulado, número de loops e se apareceu Seq Scan em tabela grande. Buffers, com EXPLAIN (ANALYZE, BUFFERS), mostra o que veio de disco.

A regra prática é colocar primeiro as colunas usadas com igualdade e depois as de faixa ou ordenação. Um índice em cliente_id e criado_em atende filtro por cliente com ORDER BY data; o inverso não atende. O prefixo à esquerda é o que o planejador consegue aproveitar, então coluna seletiva na frente.

É quando o código faz uma consulta para buscar a lista e mais uma por cada item retornado. Duzentos registros viram duzentas e uma idas ao banco. Aparece fácil no pg_stat_statements: uma query curta com calls altíssimo e tempo total absurdo. A correção costuma ser join, IN ou eager loading no ORM.

O VACUUM recupera espaço de tuplas mortas e atualiza estatísticas, evitando bloat e wraparound de transaction id. O autovacuum resolve a maioria dos casos, mas trava em tabela muito grande com escrita constante, em transação longa aberta e em replication slot esquecido. Aí você ajusta scale factor por tabela ou roda manual.

O log traz as duas transações, as queries e os recursos envolvidos quando log_lock_waits está ativo. O deadlock_timeout padrão é um segundo: antes disso o servidor só espera. Para lock comum, consulte pg_locks junto com pg_stat_activity. A causa quase sempre é ordem diferente de atualização entre dois fluxos.

Cada conexão no PostgreSQL é um processo do sistema operacional, com custo de memória e de troca de contexto. Aplicação com muitos workers curtos derruba o servidor antes de esgotar CPU. PgBouncer em modo transaction segura centenas de clientes sobre poucas conexões reais. Só lembre que esse modo quebra prepared statement e advisory lock de sessão.

Resolve escala de leitura, não query ruim. Se a consulta faz Seq Scan em dez milhões de linhas, ela vai fazer o mesmo na réplica. Réplica ajuda em relatório, BI e leitura de dashboard. O preço é lag de replicação e leitura desatualizada, o que quebra fluxo que grava e lê em seguida.

Particionamento ganha quando existe recorte natural, quase sempre data, e você precisa descartar período inteiro com DROP em vez de DELETE. O PostgreSQL faz partition pruning só se o filtro usar a chave de partição. Tabela de cem milhões de linhas com índice bom raramente precisa disso; log de evento com retenção precisa.

Índice custa escrita, espaço e trabalho do autovacuum. Não crie em coluna de baixa cardinalidade que o planejador vai ignorar. Também não vale índice em tabela pequena que cabe em memória, nem cópia do prefixo de um índice composto que já existe. Confira pg_stat_user_indexes e apague o que tem idx_scan zerado.

Ainda não. O projeto está em desenvolvimento e nada de preço foi fechado. A intenção é ter uma camada gratuita para análise pontual de plano de execução e um plano pago para quem quer histórico e integração com o banco. Se quiser acompanhar ou opinar no escopo, fale por ft.ia.br.

Sim, aidba.com.br está disponível para venda ou parceria. É um .com.br curto que junta IA e DBA, dois termos que o público de banco de dados busca todo dia. Se você quer construir produto, conteúdo ou consultoria nessa área, chame em ft.ia.br para falar de proposta.