Um testador deseja limpar uma tabela intermediária antes de uma nova execução de teste. Deveria ser DELETE, TRUNCATE ou DROP? A escolha errada pode significar um trabalho lento, uma mesa faltando ou, na produção, uma tarde muito ruim.

Executamos os exemplos DELETE e DROP abaixo no SQLite 3.50, e as saídas vêm dessa execução. SQLite não tem comando TRUNCATE, então as notas TRUNCATE são baseadas na documentação oficial do PostgreSQL, MySQL e SQL Server, e não em nosso próprio teste.

A resposta curta

• Precisa remover algumas linhas? Utilize DELETE ... WHERE.
• Precisa esvaziar uma mesa, mas mantê-la? Use TRUNCATE, onde for suportado.
• Precisa que a mesa desapareça para sempre? Utilize DROP TABLE.

DELETE: remove linhas

DELETE é um comando de alteração de dados (DML). Ele remove uma linha por vez, dispara gatilhos em nível de linha e pode ser filtrado. Montamos uma pequena tabela com um gatilho de auditoria:

CREATE TABLE logs (id INTEGER PRIMARY KEY AUTOINCREMENT, level TEXT);
INSERT INTO logs (level) VALUES ('INFO'),('ERROR'),('INFO'),('DEBUG');

CREATE TABLE audit (msg TEXT);
CREATE TRIGGER logs_delete AFTER DELETE ON logs
BEGIN INSERT INTO audit VALUES ('deleted ' || OLD.id); END;

DELETE FROM logs WHERE level = 'DEBUG';

SELECT id, level FROM logs;  -- (1,'INFO'), (2,'ERROR'), (3,'INFO')
SELECT * FROM audit;         -- 'deleted 4'

Apenas a linha correspondente foi e o gatilho a registrou. A execução de DELETE FROM logs sem uma cláusula WHERE removeu as outras três linhas e a tabela de auditoria manteve quatro entradas, uma por linha excluída.

DELETE não redefine contadores de incremento automático. Depois de esvaziar a tabela, nossa próxima inserção recebeu id 5, e não 1. No SQLite isso ocorre por causa de AUTOINCREMENT. As colunas de identidade do MySQL InnoDB e do SQL Server também continuam de onde estavam após um DELETE.

TRUNCATE: esvazia a tabela

TRUNCATE TABLE logs; remove todas as linhas de uma vez. Não pode aceitar uma cláusula WHERE. Em vez de excluir as linhas uma por uma, o banco de dados normalmente libera as páginas de dados da tabela, por isso é muito mais rápido em tabelas grandes.

Ao rodarmos no SQLite, obtivemos um erro de sintaxe, pois o SQLite não possui o comando:

TRUNCATE TABLE logs;
-- near "TRUNCATE": syntax error

No SQLite, use DELETE FROM logs; sem cláusula WHERE. A documentação do SQLite descreve uma “otimização truncada” que torna isso rápido quando a tabela não possui gatilhos. Nossa tabela tinha um gatilho, então a exclusão era executada linha por linha e disparada para cada linha.

Em bancos de dados que suportam TRUNCATE, pela sua documentação:

• Normalmente não dispara gatilhos DELETE em nível de linha.
• Geralmente redefine os contadores de identidade ou de incremento automático, por exemplo, no MySQL e no SQL Server. No PostgreSQL você adiciona RESTART IDENTITY.
• Precisa de permissões mais fortes que DELETE na maioria dos sistemas.

DROP: remova a própria tabela

DROP TABLE é um comando de esquema (DDL). Remove os dados, a definição da tabela, seus índices, gatilhos e restrições. Qualquer coisa que se refira à tabela, como visualizações ou chaves estrangeiras, também será afetada.

DROP TABLE logs;
SELECT * FROM logs;
-- no such table: logs

DROP TABLE IF EXISTS logs;  -- no error, even though it is gone

IF EXISTS é útil em scripts de configuração que podem ser executados mais de uma vez. As visualizações em uma tabela eliminada podem falhar, como mostramos em explicações das visualizações SQL.

Tabela de comparação

Você pode reverter?

É aqui que muitos artigos simplificam demais. A resposta honesta é que depende do banco de dados.

DELETE pode ser revertido dentro de uma transação em qualquer lugar. Nós testamos:

BEGIN;
DELETE FROM logs;
SELECT COUNT(*) FROM logs;  -- 0
ROLLBACK;
SELECT COUNT(*) FROM logs;  -- 3

DROP também foi revertido no SQLite, que suporta DDL transacional:

BEGIN;
DROP TABLE logs;
ROLLBACK;
SELECT COUNT(*) FROM logs;  -- 1 (the table is back)

Para TRUNCATE e DROP em outros bancos de dados, de acordo com sua documentação:

Portanto, “TRUNCATE nunca pode ser revertido” é errado para PostgreSQL e SQL Server, e “sempre pode ser revertido” é errado para MySQL. Fora de uma transação, nenhuma delas pode ser desfeita sem um backup.

Por que TRUNCATE é rápido

DELETE registra cada linha removida para que a alteração possa ser desfeita e replicada, dispara gatilhos e verifica restrições linha por linha. Em uma tabela com milhões de linhas, isso cria muito trabalho e volume de log. TRUNCATE geralmente desaloca o armazenamento em uma operação, registrando muito menos. Para remover um subconjunto grande em vez de tudo, exclua em lotes para evitar bloqueios longos. Cobrimos os custos de bloqueio e consulta na otimização de consultas SQL.

Chaves estrangeiras e permissões

• Chaves estrangeiras. O SQL Server se recusa a TRUNCAR uma tabela referenciada por uma chave estrangeira. O PostgreSQL também exige que você trunque as tabelas de referência ou use CASCADE. Em vez disso, um DELETE verifica cada linha em relação às restrições.
• Permissões. DELETE precisa de direitos de exclusão. TRUNCATE geralmente precisa de ALTER ou de um direito TRUNCATE dedicado, e DROP precisa de propriedade ou ALTER no esquema.
• Replicação e auditoria. Se outros sistemas dependerem de logs ou gatilhos de alterações em nível de linha, TRUNCATE poderá ignorá-los. Verifique primeiro com quem possui esses sistemas.

Qual usar

Para dados de teste, TRUNCATE é popular porque redefine IDs, o que torna os testes repetíveis. Agrupar cada teste em uma transação que é revertida é outra opção, explicada em Transações SQL e ACID.

Lista de verificação de segurança

1. Confirme a qual banco de dados e ambiente você está conectado.
2. Execute a cláusula WHERE como um SELECT primeiro.
3. Envolva a alteração em uma transação onde seu banco de dados a suporte.
4. Tenha um backup recente e testado antes de TRUNCATE ou DROP em produção.
5. Coloque instruções DROP em scripts de migração revisados, nunca em consoles ad-hoc.
6. Verifique o que depende de uma tabela, como visualizações, chaves estrangeiras e relatórios, antes de descartá-la.

Excluindo grandes quantidades de dados com segurança

A remoção de milhões de linhas com um DELETE pode bloquear a tabela por um longo tempo, preencher o log de transações e retardar a replicação. Um padrão comum é excluir em pequenos lotes e repetir até não sobrar nada:

-- SQL Server style (not run for this article)
DELETE TOP (5000) FROM logs WHERE created_at < '2026-01-01';

-- PostgreSQL style (not run for this article)
DELETE FROM logs
WHERE id IN (SELECT id FROM logs WHERE created_at < '2026-01-01' LIMIT 5000);

Execute a instrução em um loop, com uma pequena pausa entre os lotes, até que ela relate zero linhas. Cada lote é uma transação pequena, portanto os bloqueios são curtos e outras consultas continuam em execução. Um índice na coluna do filtro, aqui created_at, mantém cada lote rápido.

Para dados que crescem por data, como logs e eventos, o particionamento de tabelas é ainda melhor. Cada mês reside em sua própria partição, e a remoção de dados antigos torna-se uma operação rápida que elimina ou trunca uma partição em vez de excluir linhas uma por uma.

Exclusões suaves

Muitos aplicativos nunca excluem fisicamente registros comerciais. Eles adicionam uma coluna como deleted_at e a definem, e as consultas são filtradas em deleted_at IS NULL. As exclusões suaves facilitam a recuperação e mantêm o histórico para auditorias, mas cada consulta deve lembrar o filtro, o que é um bom trabalho para uma visualização. As restrições exclusivas também precisam de cuidado, porque uma linha excluída de forma reversível ainda mantém seu valor. As leis de privacidade podem exigir a exclusão real de dados pessoais após um período, portanto, as exclusões suaves não substituem uma política de retenção.

Considerações finais

DELETE é a ferramenta precisa e cuidadosa. TRUNCATE é o botão de reinicialização rápida e DROP remove totalmente a tabela. O maior risco é assumir que um banco de dados se comporta como outro, especialmente durante a reversão. Em caso de dúvida, teste primeiro o comando em uma cópia da tabela em seu próprio banco de dados.

Perguntas frequentes

Continue aprendendo