truncate能秒删百万行数据，因其本质是“换表”而非删数据：释放原表段并新建空段，跳过行级锁、undo log、redo log等dml开销，仅记一条ddl日志，不触发触发器，且隐式提交、不可回滚。
TRUNCATE 为什么能绕过 InnoDB 的行级日志路径
因为 TRUNCATE TABLE 在 InnoDB 中不是“删数据”，而是“换表”：它调用 ha_innobase::truncate()，内部执行的是「释放原表段（segment）+ 新建空段」。不走 row_delete_for_mysql() 流程，也就跳过了逐行加锁、生成 undo log、写 redo log 记录变更的全套 DML 开销。
常见错误现象：DELETE FROM t 在千万级表上执行数小时、SHOW PROCESSLIST 卡在 Updating 状态、innodb_log_file_size 频繁刷盘——这些全是 DML 日志链路被压垮的表现；而 TRUNCATE TABLE t 几乎瞬时返回，SHOW ENGINE INNODB STATUS 里看不到相关事务堆积。
- DELETE 每删一行，都要在 undo log 里存一份镜像，用于 MVCC 和回滚；TRUNCATE 完全不写 undo log
- binlog 中，DELETE 会按行或语句记录大量事件；TRUNCATE 只记一条
TRUNCATE TABLE tDDL 事件 - 触发器（
BEFORE/AFTER DELETE）对 TRUNCATE 完全无效，省去调用开销
TRUNCATE 真正释放磁盘空间的关键前提
TRUNCATE 能否让 .ibd 文件变小，取决于 innodb_file_per_table 是否为 ON。只有开启该选项，TRUNCATE 才会真正删除并重建独立表空间文件；否则空间仍留在共享表空间 ibdata1 中，无法被操作系统回收。
使用场景：清理日志表、ETL 临时中间表——这类表通常已启用 innodb_file_per_table=ON，TRUNCATE 后 ls -lh table_name.ibd 可见文件大小归零或回到初始值。
- 执行后立刻验证：
SELECT DATA_LENGTH, INDEX_LENGTH FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='t'，值应大幅下降 - 若值不变，先查
SHOW VARIABLES LIKE 'innodb_file_per_table'；为OFF时，TRUNCATE 不释放物理空间 - 共享表空间下想彻底回收，只能导出数据 +
DROP TABLE+ 重建 + 导入
为什么 TRUNCATE 会重置 AUTO_INCREMENT 却不触发外键检查
TRUNCATE 重置自增值，是因为它直接修改了内存中表元数据结构 dict_table_t::autoinc 字段；而外键约束检查被跳过，是因为它的实现绕过了存储引擎层的 DML 校验入口（如 row_ins_check_foreign_constraints()），属于 DDL 级元数据操作。
容易踩的坑：业务用自增 ID 做外部系统序列号，TRUNCATE 后首次插入可能撞上历史 ID；但更隐蔽的问题是——有子表通过外键引用该表时，TRUNCATE TABLE t 直接报错 ERROR 1701 (HY000)，根本不会走到重置逻辑这一步。
- 检查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME='t' - 想保留自增连续性？别用 TRUNCATE，改用
DELETE FROM t+ALTER TABLE t AUTO_INCREMENT = N（注意后者本身是隐式 DDL，大表慎用） - MySQL 8.0+ 支持
SET FOREIGN_KEY_CHECKS = 0临时关闭，但 TRUNCATE 仍拒绝执行——这是硬限制，非开关可绕过
TRUNCATE 在事务中隐式提交的真实影响
执行 TRUNCATE TABLE t 会立即触发隐式 COMMIT，当前事务就此结束。这不是“建议”或“副作用”，而是 MySQL DDL 的强制行为：任何 DDL 语句（包括 CREATE、ALTER、TRUNCATE）都会中断事务上下文。
常见错误现象：在一个长事务里先更新订单状态，再 TRUNCATE 日志表，最后 ROLLBACK——结果订单更新已提交，日志表也空了，事务一致性完全破坏。
- 开发常误以为 “TRUNCATE 快所以适合放事务里”，实际它和
COMMIT效果等价 - 替代方案：若必须原子性清空+写入，用
RENAME TABLE交换表名（如t_old↔t_new），再异步DROP或TRUNCATE旧表 - 复制环境下，
binlog_format=STATEMENT时 TRUNCATE 可能不被从库识别（5.7+ 默认MIXED或ROW，基本安全）
