DELETE导致事务日志满，根本不是“删得多”，而是单事务过长——每行删除都记完整镜像，百万行即百万镜像，撑爆undo log或ldf；TRUNCATE只记页级操作、不支持WHERE、不触发触发器、不可回滚且禁用于外键引用表；分批DELETE必须用ORDER BY+LIMIT或BETWEEN主键区间、建联合索引、检查ROW_COUNT()、及时ANALYZE TABLE。
直接说结论：DELETE 导致事务日志满，不是因为“删得多”，而是因为默认把整批操作塞进一个长事务里；TRUNCATE 不记逐行日志，自然不爆日志；但不能乱换——它不支持 WHERE、不触发触发器、不能回滚，且对有外键引用的表直接报错。
DELETE 为什么一跑就报 “事务日志已满”（错误 9002）
根本原因是：每删一行，InnoDB（MySQL）、SQL Server 或 PostgreSQL 都得在 undo log 或事务日志里存一份“删除前的完整镜像”。删 100 万行，就写 100 万份镜像。日志文件（ib_logfile、ldf 或 pg_wal）瞬间撑爆，同时所有被扫描到的行持续持锁，连带阻塞其他查询。
常见现象包括：
- 执行中卡住，
SELECT COUNT(*)也变慢甚至超时 - SQL Server 报错：
消息 9002，级别 17，状态 4 - MySQL 报错：
Undo log is full或Transaction too large -
log_reuse_wait_desc查出来是LOG_BACKUP或ACTIVE_TRANSACTION
TRUNCATE 能解决日志问题，但有硬限制
TRUNCATE 是 DDL 操作，它不逐行删除，而是直接释放数据页，在日志里只记“页被清空”这一条元信息。所以日志增长极小、速度快、不走触发器。
但它只适用于特定场景：
- 必须清空整张表——
TRUNCATE TABLE orders合法，TRUNCATE TABLE orders WHERE status = 'archived'语法错误 - 表不能被 FOREIGN KEY 引用，否则报错：
Cannot truncate a table referenced in a foreign key constraint - 不能用于参与索引视图的表（SQL Server）或临时表（某些 MySQL 版本）
- 执行后自增 ID 重置，如果业务依赖连续 ID 或当前值，会出问题
分批 DELETE 的实操要点：ORDER BY + LIMIT + 独立事务
要保留条件过滤能力，又不爆日志，唯一可靠方式是分批提交。但光写 DELETE ... LIMIT 5000 很容易翻车。
关键控制点：
- 必须加
ORDER BY id（或其他有索引的确定性列），否则优化器可能跳过行或重复删——尤其并发写入时 - WHERE 条件字段和 ORDER BY 字段建议建联合索引，例如
INDEX idx_status_id (status, id) - 别用
LIMIT 5000 OFFSET 10000：OFFSET 越大越慢，还可能漏掉新插入的行 - 更稳的做法是主键区间分段：
DELETE FROM t WHERE id BETWEEN 10001 AND 15000 AND status = 0 - 每次执行后检查
ROW_COUNT()，为 0 就停；别用COUNT(*)判定是否继续
循环节奏不能靠固定 sleep，要看数据库负载
在存储过程或脚本里写 WAITFOR DELAY '00:00:00.1'（SQL Server）或 SLEEP(0.2)（MySQL）只是权宜之计。IO 压力大时，这点延迟不够释放日志空间；空闲时又白白拖慢进度。
真正可控的做法是：
- SQL Server：配合
BACKUP LOG或检查点触发，确保日志可截断 - MySQL：确认
innodb_undo_log_truncate=ON，且innodb_max_undo_log_size设置合理 - PostgreSQL：删完及时跑
VACUUM，避免膨胀，同时注意pg_xact目录不被长期占用 - 所有数据库：高峰期避开业务波峰，临时关掉
auto_update_stats（SQL Server）或innodb_stats_auto_recalc（MySQL）
最易被忽略的一点：分批 DELETE 后，统计信息可能严重滞后，导致后续查询走错执行计划——删完务必手动 ANALYZE TABLE t（MySQL）或 UPDATE STATISTICS（SQL Server）。
