TRUNCATE TABLE是唯一能真正快速清空大表且不占用事务日志的原生命令，它通过释放数据页、重置AUTO_INCREMENT、跳过undo log和行级binlog实现毫秒级清空，但必须满足无外键依赖、具备DROP权限、无长事务阻塞三前提。
TRUNCATE TABLE 是唯一能真正满足“快速清空大表数据且不占用事务日志”的原生命令。
它不是逐行删，而是直接释放数据页、重置 AUTO_INCREMENT、跳过 undo log 和行级 binlog（ROW 格式下），实测清空 1 亿行通常在毫秒级。但它的硬性前提必须全部满足，否则一执行就失败或引发事故。
为什么只有 TRUNCATE TABLE 不写事务日志
它本质是 DDL 操作，不是 DML：DELETE 走的是 InnoDB 行删除路径，每行都要记 undo、维护 MVCC、更新索引、加间隙锁；而 TRUNCATE TABLE 直接丢弃整个数据段（segment），连 buffer pool 里对应页都标记为可复用，完全绕开事务日志链路。
注意：statement-based binlog 下仍会记一条语句日志；row-based 下默认不记录被删的每一行——这才是“不占用事务日志”的真实含义。它不生成 undo log，也就不会拖慢 purge 线程，更不会导致 ibdata1 或 undo 表空间暴涨。
TRUNCATE TABLE 执行前必须检查的三件事
它失败时不会给你第二次机会，报错就中断，常见卡点全是权限或约束层面的：
- 查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table' AND REFERENCED_TABLE_SCHEMA = 'your_db';—— 只要结果非空，TRUNCATE必报ERROR 1701 - 确认权限：
SHOW GRANTS;中必须含DROP权限（不是DELETE或ALTER） - 检查事务状态：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id != CONNECTION_ID();—— 若有长事务正在读该表，TRUNCATE会阻塞，而非报错
误用 DELETE FROM table_name 的典型后果
很多人以为加了 WHERE 就安全，但漏掉条件后就是灾难起点。一旦执行 DELETE FROM huge_log;（无 WHERE），后果立现：
- 事务日志（redo/undo）瞬间暴涨，可能填满磁盘
- InnoDB 持有全表范围的间隙锁（gap lock），后续
INSERT/UPDATE全部等待 - 主从复制延迟飙升——row-based binlog 会把每行的
before image全记下来，网络和 IO 压力翻倍 - 即使你立刻
KILL，回滚过程本身也比删除更慢，且期间表仍不可用
真要保留部分数据？别碰 TRUNCATE，改用替换法
只要需求里带“保留最近 N 天”“只留活跃用户”，TRUNCATE 就完全不适用。这时候必须放弃“清空”思维，转向“重建”：
- 用
CREATE TABLE new_table LIKE old_table;复制结构（含索引、分区） - 用
INSERT INTO new_table SELECT ... FROM old_table WHERE ...;只导入要保留的数据（建议离峰执行、分批控制内存） - 用
RENAME TABLE old_table TO old_table_bak, new_table TO old_table;原子切换 - 确认业务无异常后，再
DROP TABLE old_table_bak;
这个过程不锁原表读，切换瞬间完成，但要注意：新表没数据时，业务查询会短暂报错；另外，如果原表有触发器、存储过程强依赖表名，需同步调整。
