Banco de dados que se auto-otimiza:
como funciona o self-tuning do Catcher Data

Tuning manual é reativo por natureza

O ciclo é conhecido. O app fica lento, alguém abre o painel de métricas, roda EXPLAIN em duas ou três queries suspeitas e cria um índice direto em produção. Funciona até a próxima vez. Ninguém volta para revisar se aquele índice ainda faz sentido, se a flag copiada de um post antigo serve para o seu workload, ou se a query que era rara no lançamento virou a mais executada do sistema.

O problema não é competência. É rotina. Tuning bem feito exige olhar o workload real com frequência, e quase nenhum time de produto tem alguém com esse mandato. Na maioria dos SaaS, o banco só recebe atenção quando dói — e aí o trabalho vira diagnóstico sob pressão, não otimização. Slow queries acumulam em silêncio porque, na prática, ninguém está olhando.

E o custo é composto. Cada índice criado no susto vira legado que ninguém tem coragem de remover. Cada flag ajustada sem registro vira arqueologia na próxima investigação. Dois anos depois, a instância carrega camadas de decisões que ninguém sabe mais justificar — e o medo de mexer cresce na proporção exata da falta de evidência.

O que o self-tuning faz

O self-tuning do Catcher Data transforma esse trabalho em um pipeline contínuo, exposto no painel Tuning do console, por instância do Database. São cinco etapas:

1. Coleta de workload real. O slow query log da instância é ativado de forma gerenciada e passa a registrar o que de fato roda em produção. Nada de carga sintética ou benchmark genérico: a matéria-prima é o seu tráfego.
2. Findings. O workload coletado é analisado e vira uma lista de findings — índice ausente, flag mal dimensionada, padrão de query que não escala. Cada finding carrega a evidência que o gerou.
3. Simulação. Antes de tocar em qualquer coisa, você simula o impacto da mudança proposta sobre o workload registrado.
4. Aplicação com 1 clique. Aprovou a simulação, aplica. A mudança é executada de forma controlada na instância.
5. Rollback. Toda ação aplicada pelo painel é reversível. Se o resultado não for o esperado, você volta ao estado anterior.

Funciona nas instâncias MySQL 8 e PostgreSQL 16 gerenciadas pelo Catcher Data, com dados hospedados no Brasil (região southamerica-east1, em São Paulo) e console em português.

O ciclo de um finding

Um finding não é um alerta que pisca e some. É um objeto com ciclo de vida explícito: nasce detectado, carrega a evidência que o gerou, passa por simulação e — só se você mandar — é aplicado, com o caminho de rollback registrado antes do clique. Cada transição fica visível no painel, e nenhuma acontece sozinha.

Estado	O que significa	Próximo passo
Detectado	O analisador identificou um padrão no workload e anexou a evidência: queries envolvidas, frequência, custo observado	Ler a evidência; simular ou dispensar
Simulado	A plataforma estimou o impacto da mudança sobre as queries registradas — as que melhoram e as que podem piorar	Comparar ganho e custo; aplicar ou descartar
Aplicado	A mudança foi executada na instância, com o estado anterior registrado para reversão	Acompanhar o efeito no workload seguinte
Revertido	O rollback restaurou o estado anterior da instância	Reavaliar o finding com a evidência atualizada

Duas propriedades desse desenho importam. A primeira: nenhum finding pula etapas — não existe caminho do estado detectado direto para aplicado sem passar pela sua decisão. A segunda: auditabilidade. Seis meses depois, você consegue responder o que foi aplicado, quando, com base em qual evidência e como desfazer. Tuning manual não deixa esse rastro — a migration do índice até fica no repositório, mas o porquê se perde na conversa em que foi decidido.

Dispensar também é desfecho legítimo. Você conhece o app melhor do que qualquer analisador de workload: se um finding propõe índice numa tabela que será removida no próximo trimestre, dispense e siga. O valor do ciclo está em decidir com evidência, não em aceitar tudo.

Por que simular antes de aplicar

Recomendação de índice é fácil de gerar e fácil de aplicar errado. Todo índice tem custo: escrita mais cara, mais espaço em disco, mais um caminho para o otimizador avaliar. Uma flag alterada muda o comportamento global da instância, não só o da query que motivou a mudança. E o efeito combinado de duas mudanças raramente é a soma dos efeitos individuais.

Por isso a simulação é uma etapa própria do fluxo, não um detalhe. Ela responde à pergunta que separa uma boa mudança de uma aposta: o que acontece com o meu workload se eu aplicar isso? Você vê o impacto estimado sobre as queries reais que a coleta registrou — as que melhoram e as que podem piorar — antes de qualquer alteração chegar à instância. Aplicar sem simular é a versão moderna de criar índice em produção na sexta-feira à tarde.

A simulação também muda a conversa dentro do time. Em vez de "acho que esse índice ajuda", a discussão vira "a simulação estima ganho nas cinco queries mais frequentes e custo marginal de escrita na tabela de pedidos". Dá para discordar de uma estimativa. Mas a discussão parte de evidência, não de opinião — e termina em decisão, não em aposta.

Por que managed flags mudam tudo

A coleta de workload começa ativando o slow query log — e é aqui que a automação mostra se entende a plataforma que opera. As instâncias do Catcher Data rodam em Cloud SQL, e no Cloud SQL slow_query_log, long_query_time e log_output são managed flags: pertencem à plataforma, não à sessão. SET GLOBAL falha com access denied — o usuário administrativo do Cloud SQL não tem esse privilégio, por desenho. O caminho clássico do manual do MySQL simplesmente não existe aqui.

O caminho correto é a Cloud SQL Admin API, atualizando as databaseFlags da instância. E aqui mora a pegadinha que separa quem operou Cloud SQL de quem leu o quickstart: o PATCH substitui a lista inteira de flags. Não existe "adicionar uma flag" — existe enviar a lista completa que a instância deve ter dali em diante. Por isso o self-tuning faz o fluxo em três passos: GET para ler as flags atuais, merge das novas sobre as existentes, PATCH do conjunto completo.

# Errado — falha no Cloud SQL (managed flag):
SET GLOBAL slow_query_log = 'ON';
-- access denied: privilégio reservado à plataforma

# Certo — GET → merge → PATCH via Admin API:
GET   https://sqladmin.googleapis.com/v1/projects/{project}/instances/{instance}
# lê as databaseFlags atuais e mescla as novas sobre elas
PATCH https://sqladmin.googleapis.com/v1/projects/{project}/instances/{instance}
{
  "settings": {
    "databaseFlags": [
      { "name": "cloudsql_iam_authentication", "value": "on" },
      { "name": "slow_query_log",              "value": "on" },
      { "name": "long_query_time",             "value": "1" },
      { "name": "log_output",                  "value": "FILE" }
    ]
  }
}

O exemplo concreto do que um patch ingênuo destrói: a instância autentica conexões via IAM, com cloudsql_iam_authentication=on — é essa flag que sustenta a conexão keyless, sem senha trafegando entre serviços. Um PATCH que envia só as flags do slow log apaga a flag de IAM da lista. A autenticação keyless desliga, e toda conexão que dependia dela cai junto. Você queria ativar um log e derrubou o acesso ao banco. O merge não é elegância de implementação — é a diferença entre ganhar observabilidade e abrir um incidente.

Um segundo detalhe que a automação precisa saber: essas três flags são dinâmicas — a mudança vale sem reiniciar a instância, e ativar a coleta não custa downtime. Outras flags forçam restart, e aí a aplicação deixa de ser gratuita. O finding informa de qual caso se trata antes de você clicar: mudança a quente ou mudança que pede janela.

Como um finding se parece

Cada finding segue o mesmo contrato: o que foi detectado, a evidência que sustenta, a ação proposta e se ela é reversível. Um exemplo ilustrativo do que aparece no painel:

Finding	Evidência	Ação proposta	Reversível?
Índice ausente	Full scans recorrentes no slow query log, sempre filtrando pela mesma coluna	Criar índice secundário na coluna filtrada	Sim — rollback remove o índice
Flag mal dimensionada	Leituras indo a disco com memória disponível na instância	Ajustar a flag via Admin API, com merge	Sim — restaura o valor anterior
Threshold do slow log alto demais	Quase nenhuma query registrada, com latência do app oscilando	Reduzir long_query_time para capturar o workload real	Sim
Ordenação sem índice	Filesort recorrente em consulta paginada	Criar índice composto cobrindo filtro e ordenação	Sim — rollback remove o índice

A coluna que importa é a última. Toda ação proposta nasce com o caminho de volta definido. Se não dá para reverter com segurança, não entra no painel como ação de um clique.

O que fica de fora (e por quê)

Automação séria se define tanto pelo que faz quanto pelo que recusa fazer. Três limites do self-tuning são deliberados — e vale entender o porquê de cada um.

Ele não reescreve as queries do seu app. Quando o padrão problemático nasce no código — um N+1 gerado pelo ORM, uma paginação por OFFSET profundo, um SELECT sem critério em tabela larga — o finding aponta o padrão e anexa a evidência, mas a correção pertence ao seu repositório. O que é operável do lado do banco (índice, flag) vira ação de um clique; o que é código de aplicação vira evidência pronta para o backlog. Reescrever queries por trás do seu ORM seria mágica frágil: quebraria na próxima versão do app, longe dos seus testes e do seu code review.

Ele não aplica nada sozinho. Não cria índice por conta própria, não altera flag de madrugada, não "otimiza" nada sem comando seu. Coleta, analisa, propõe e simula — a decisão de aplicar é sempre sua, sempre explícita, com o rollback definido antes do clique. Isso não é limitação temporária esperando você confiar mais na ferramenta; é desenho de produto. Mudança em banco de produção sem operador ciente é risco, não conveniência.

Findings dependem de workload real acumulado. Instância recém-criada não gera finding — não há o que analisar. Staging com carga sintética gera findings sobre a carga sintética, que valem pouco para produção. A qualidade das recomendações cresce com o tempo de coleta: mais workload registrado significa evidência mais representativa e simulação mais confiável. É o oposto de um linter estático de schema — e é exatamente por isso que ele acerta onde o linter chuta.

Onde isso se encaixa no seu fluxo

A recomendação é tratar o painel Tuning como um code review periódico. Leia os findings novos, simule os que fazem sentido, aplique os aprovados e acompanhe o efeito. O self-tuning cuida da parte que nenhum time sustenta de forma consistente — olhar o workload real toda semana — e devolve para você só o que importa: decisões com evidência. A ativação da coleta e a referência completa do fluxo estão na documentação do Database.

Para incidentes — quando algo degrada agora e você precisa de causa raiz, não de otimização — existe outra peça da plataforma: o DBA autônomo, que abre incidentes com RCA e correção sugerida. Os dois compartilham a mesma filosofia: explicar antes de agir, e nunca agir sem você.