“Se o InnoDB guarda versões antigas… quem limpa essa bagunça?”
No post anterior, vimos que:
👉 DELETE não apaga imediatamente
👉 versões antigas ficam no Undo Log
👉 múltiplas versões coexistem por causa do MVCC.
💥 Purge Thread.
🧠 1. O que é o Purge Thread?
Você pode pensar nele como:
🧹 um processo em background responsável por limpar versões antigas de dados
Mais tecnicamente:
- ele percorre o undo log
- remove versões que não são mais necessárias
- libera espaço interno dentro do InnoDB.
📌 Definição direta
O Purge só remove dados quando nenhuma transação precisa mais deles.
Ou seja: 👉 ele depende diretamente do MVCC….
⚙️ 2. Quando o Purge pode trabalhar?
O Purge Thread só pode agir quando:
✅ todas as transações que poderiam enxergar a versão antiga já terminaram
✅ aquela versão não é mais necessária para leitura consistente
✅ não há necessidade de rollback
💡 E aqui está o ponto crítico:
O MySQL é conservador — ele prefere manter dados antigos do que quebrar consistência.
🔥 3. Fluxo completo agora (entendendo o contexto do post 1 e 2).
Aqui você conecta toda a série até agora:
🚨 4. Quando o Purge NÃO consegue acompanhar
Aqui começa a parte que mais importa em ambiente real.
⚠️ Cenário clássico:
Você tem:
- aplicação com transações abertas
- relatórios longos
- conexão esquecida sem COMMIT
👉 Resultado:
O Purge fica travado esperando essas transações terminarem.
💣 Consequências:
📈 1) Crescimento do Undo Log
- mais versões antigas acumuladas
- consumo de espaço
🐌 2) Queda de performance
- mais versões para verificar
- leitura mais custosa
📦 3) Tabela “não encolhe”
- conecta diretamente com o Post 1 (onde apresentei sobre o delete).
- espaço continua ocupado.
🚨 5. Sintoma real que muita gente ignora.
O banco começa a:
- ficar mais pesado
- crescer em disco
- demorar mais nas queries
E ninguém sabe o motivo 😅
👉 Mas o problema é:
O Purge não está conseguindo acompanhar o volume de mudanças.
⚠️ 7. Por que isso acontece na prática?
Principais causas:
🔴 1) Transações longas
- SELECT aberto.
- job demorando.
🔴 2) Aplicação sem controle de transação
- BEGIN sem COMMIT.
- connection pool mal utilizado.
🔴 3) Alto volume de DELETE/UPDATE
- gera muitas versões.
- aumenta backlog do purge.
🧠 8. Resumo (o mais importante da série até agora)
👉 DELETE não apaga.
👉 MVCC mantém versões.
👉 Undo Log guarda histórico.
👉 Purge Thread limpa… quando consegue.
Agora você já entendeu tudo.
Mas falta o último ponto:
“Se o Purge limpa… por que o arquivo da tabela continua grande?”
E mais importante:
“Como recuperar espaço de verdade no MySQL?”
👉 No próximo (e último) post da série:
💥 Por que sua tabela nunca diminui (e quando usar OPTIMIZE TABLE).
Referências.
MySQL Docs – Innodb Undo Logs.
