“Se o DELETE não apaga de verdade… então o que exatamente ele faz?”
No post anterior, vimos que:
👉 você apaga dados
👉 mas o espaço não some
Agora vem a resposta completa:
💥 Porque o dado não é apagado imediatamente.
E isso tem nome:
🧠 MVCC (Multi-Version Concurrency Control)
🧩 1. O segredo do InnoDB: múltiplas versões do mesmo dado
O InnoDB funciona assim:
👉 Ele mantém versões antigas das linhas
👉 Para garantir consistência entre transações
Ou seja:
✅ Seu DELETE não “remove” a linha na hora
✅ Ele cria uma nova versão da linha (marcada como deletada).
Por baixo dos panos.
Quando você roda:
|
1 |
DELETE FROM sbtest1 WHERE id = 500001; |
O InnoDB faz algo equivalente a:
- marca a linha como deletada
- mantém a versão antiga
- guarda informações no Undo Log
💡 Isso não é teoria — é comportamento documentado (MySQL Docs):
O DELETE é tratado internamente como uma atualização que marca a linha como removida, mantendo versões anteriores para leitura consistente.
🧪 Demonstração prática (com sysbench)
Vamos ver isso acontecendo na prática.
🔍 1) Criar uma transação longa (Sessão 1)
|
1 2 |
START TRANSACTION; SELECT * FROM sbtest1 WHERE id = 500001; |
🔥 2) Em outra sessão, fazer DELETE
|
1 |
DELETE FROM sbtest1 WHERE id = 500001; |
😲 3) Voltamos na Sessão 1.
|
1 |
SELECT * FROM sbtest1 WHERE id = 500001; |
🤯 O que aconteceu aqui?
✅ Sessão 1 vê a versão antiga
✅ Sessão 2 já deletou o dado
✅ As duas leituras coexistem
🧠 Por que o MySQL faz isso?
Para garantir:
- consistência
- isolamento entre transações
- leitura sem lock
👉 Basicamente: ACID funcionando de verdade…..
📦 2. Onde essas versões antigas ficam?
Agora entra o protagonista:
💥 UNDO LOG
O que é o Undo Log?
É onde o InnoDB guarda:
- versões antigas de linhas
- dados para rollback
- informações pra reconstruir versões antigas
👉 Ele fica em estruturas chamadas:
- rollback segments
- undo tablespaces
|
1 |
DELETE FROM sbtest1 WHERE id = 500001; |
O MySQL guarda:
- os dados antigos.
- referência à versão anterior.
- informações da transação.
Observação importante:
Fluxo simplicado de um Delete.
⚠️ 4. O problema das versões antigas.
Agora vem a parte prática de produção:
🚨 Se você tiver:
- transações abertas por muito tempo
- relatórios rodando
- sessões esquecidas
👉 o MySQL NÃO pode apagar versões antigas.
Resultado:
- Undo log cresce
- espaço continua ocupado
- pode afetar performance
💣 Exemplo comum
- aplicação abre transação
- esquece de dar COMMIT
- DELETE roda normalmente
- mas limpeza nunca acontece
👉 cenário clássico de banco “inchando”.
Agora vem a pergunta que fecha o raciocínio:
“Quem limpa essas versões antigas?”
E mais:
“Por que às vezes isso demora ou trava?”
👉 No próximo post:
💥 Purge Thread: o ‘faxineiro’ do InnoDB que ninguém lembra.
