truncate比delete快的根本原因是它不走innodb行级处理流水线，而是原子性执行drop+create等价操作，跳过聚簇索引扫描、mvcc、undo log和逐行binlog，仅记一条ddl日志。

TRUNCATE 为什么比 DELETE 快一个数量级

根本原因不是“少写日志”，而是 TRUNCATE 根本不走 InnoDB 的行级处理流水线 —— 它跳过了聚簇索引遍历、MVCC 版本链维护、undo log 生成、binlog 逐行序列化这些开销最大的环节。

它在 InnoDB 层实际执行的是原子性等价操作：DROP TABLE + CREATE TABLE（保留原表名、列定义、索引结构），直接释放数据段、重置 FSEG_HEADER、清空 Extent 映射，并把 .ibd 文件截断回初始大小（前提是 innodb_file_per_table=ON）。

• 不扫描任何数据页，不访问 B+ 树
• 不生成 undo log 条目 → 不可回滚
• binlog 只记一条 TRUNCATE TABLE t DDL 事件（非 row/statement 模式）
• 不触发 ON DELETE 触发器，也不检查外键约束（除非被其他表引用）

DELETE FROM t 卡住大表的典型表现

哪怕没加 WHERE，DELETE FROM t 仍是一条标准 DML：InnoDB 启动事务，逐行遍历聚簇索引，对每行加 X 锁、标记 delete bit、写入 undo log、再按 binlog 格式生成日志条目。百万行 = 百万次锁/日志/刷盘。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• SHOW PROCESSLIST 显示状态为 Updating 或 Writing to net
• 主从延迟突增（尤其 binlog_format=ROW 下，单条语句生成上万 event）
• 事务长时间持有锁，阻塞其他 DML
• undo 表空间暴涨，甚至触发 innodb_force_recovery

文件系统层面的空间是否真回收了

取决于配置和存储引擎行为，不是“删了就没了”：

• 若 innodb_file_per_table=ON（默认），TRUNCATE 后 .ibd 文件大小立即回落，ls -lh 可见变化
• 若 innodb_file_per_table=OFF，数据仍在共享表空间 ibdata1 内，TRUNCATE 无法释放磁盘空间，必须重建实例
• DELETE 后即使执行 ANALYZE TABLE，也只更新统计信息，Data_length 不变；只有 OPTIMIZE TABLE 或 ALTER TABLE ENGINE=InnoDB 才能重建 .ibd 并收缩 —— 但它会锁表、复制全量数据，开销接近 TRUNCATE

误用 TRUNCATE 导致不可回滚的隐性代价

很多人只记住“快”，却忽略它绕过所有事务保障机制的副作用：

• 执行即隐式提交，ROLLBACK 无效
• 不会触发任何 DELETE 相关触发器（比如审计日志、缓存清理）
• 如果表被其他表通过外键引用，TRUNCATE 会直接报错，而 DELETE 会按约束规则级联或拒绝
• 自增 ID 会被重置为初始值，可能影响下游依赖该字段连续性的逻辑

真正危险的不是速度，是它看起来像 DELETE，实则行为更接近 DROP —— 一旦执行，连 binlog 回放都只能恢复到表空的状态，没法还原中间过程。