Estudo de caso: menos escrita no banco de produtos de dados públicos

O desafio

Vários produtos de dados públicos usam o mesmo servidor MySQL: dados de empresas, um radar de domínios novos e um catálogo de ferramentas para agentes de IA.

Em setembro de 2026, o servidor gravava de 1,1 a 2,2 TB por dia. A maior parte vinha de comandos pequenos que rodavam muitas vezes por dia.

Abordagem

• Medir antes de mudar: o resumo do performance_schema por arquivo e por comando mostra o que mais grava.
• Contar a escrita em páginas de 16 KiB, não em linhas. Com o doublewrite, cada página suja é gravada duas vezes.
• Não fazer upsert a cada evento numa tabela grande: somar em memória por hora e gravar cada chave uma vez, só se ela mudou.
• Pôr as chaves novas numa tabela quente pequena e fundi-las uma vez por dia, na ordem da chave.
• Fazer as tarefas periódicas lerem só o que mudou, pela marca de atualização, e pularem a rodada quando nada mudou.

Resultados medidos

• Tabelas temporárias em disco: de 426 para 3 por hora (−99%), na primeira hora depois do ajuste de memória (26/09/2026).
• Radar de domínios: uma escrita por domínio e hora cortou 58% das linhas, mas só 12% dos bytes (de 6,20 para 5,43 GB por hora). A página, não a linha, define o custo.
• Radar de domínios com a tabela quente: fora da fusão diária, nenhum comando grava na tabela de 126 milhões de linhas (03/10/2026).
• Catálogo de ferramentas para agentes: gravar só a diferença cortou 60% da escrita no arquivo da tabela.
• Uma métrica de monitoramento que lia 551 MiB a cada 2 minutos passou a não ler nada (03/10/2026).
• O servidor todo: de 1,1–2,2 TB por dia para 650–740 GiB por dia (medido em 03/10/2026).

• Radar CNPJ
• Agentalog

Fontes

As medidas vêm do performance_schema do MySQL (resumo por arquivo e por comando) e do registro de disco do servidor, em 26/09/2026 e 03/10/2026.

Limites

• Os números são de um servidor e de uma carga. Outro esquema precisa da medida dele.
• O total do servidor também inclui mudanças em outros sistemas do mesmo banco. Os itens acima isolam cada correção.
• Mais memória para o banco só ajuda depois que as leituras desnecessárias param. Ela não substitui a correção.

Contrate para isso

• Achar os comandos que mais custam escrita e leitura, com o número de antes e de depois.
• Reescrever as tarefas periódicas para lerem só o que mudou, e criar índices sem parar o banco.