truncate table 是清空 innodb 表最快、最彻底的方式，因其直接丢弃数据页并重建聚簇索引，不写 undo log、不触发触发器、不校验外键（除非被引用）、立即释放 .ibd 空间且重置 auto_increment 为 1。
TRUNCATE TABLE 是清空 InnoDB 表最快、最彻底的方式，但必须确认你不需要回滚、不依赖触发器、且能接受 auto_increment 重置为初始值。
TRUNCATE TABLE 为什么比 DELETE 快得多
TRUNCATE 不是逐行删除，而是直接丢弃整张表的数据页，重建空的聚簇索引结构。它绕过事务日志（不写 undo log）、不触发触发器、不校验外键约束（除非有外键被引用），也不保留任何历史记录。对 InnoDB 来说，这相当于原子性地“删掉并重建”表的存储结构。
-
DELETE FROM table_name会为每一行生成 undo log，支持事务回滚，但慢、占 redo/undo 空间，且不会释放磁盘空间（InnoDB 中） -
TRUNCATE TABLE table_name是 DDL 操作，立即释放.ibd文件占用的空间，且重置AUTO_INCREMENT计数器为 1 - 执行时若表被其他事务加了 MDL 锁（比如长事务正在查这张表），
TRUNCATE会阻塞，直到锁释放
TRUNCATE 在 InnoDB 中不生效的几种情况
看似写了 TRUNCATE TABLE 却没清空、没释放空间，大概率踩了这些坑：
- 表被外键约束引用：InnoDB 不允许 TRUNCATE 有子表依赖的父表（报错
ERROR 1701 (42000)），必须先DROP FOREIGN KEY或改用DELETE - 表上有活跃的事务或未提交的查询：会卡在等待 MDL 写锁阶段，
SHOW PROCESSLIST可看到状态为Waiting for table metadata lock - 使用了 MySQL 8.0+ 的原子 DDL 特性但配置了
innodb_dedicated_server=OFF：极少数情况下影响空间回收时机，建议检查INFORMATION_SCHEMA.INNODB_TABLESPACES确认FILE_SIZE是否已缩小 - 误把 MyISAM 行为套用到 InnoDB：MyISAM 的
TRUNCATE确实快，但 InnoDB 的空间释放还依赖后续的 purge 线程清理——不过通常几秒内就完成，SELECT FILE_SIZE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME='db/table'可验证
TRUNCATE 后空间没立刻变小？检查这三处
InnoDB 表空间文件（.ibd）大小没缩回去，不是 TRUNCATE 失败，而是空间管理机制导致的常见误解：
-
innodb_file_per_table=ON（默认）时，TRUNCATE确实会删除并重建.ibd文件，文件系统层面大小应归零——如果没变，说明命令根本没执行成功（查 error log） - 如果启用了
innodb_undo_log_truncate且 undo 表空间碎片严重，可能延迟释放；但这是 undo 空间，不影响主表.ibd - 更常见的是：你连的是从库，或执行了
TRUNCATE但没等 binlog 同步完成就去查磁盘，而.ibd删除是异步的；用ls -lh /var/lib/mysql/db/table.ibd直接看文件系统最准
真正要注意的其实是「TRUNCATE 不可逆」和「外键阻塞」这两个点，其余问题基本都能通过 SHOW ENGINE INNODB STATUS 和文件系统验证快速定位。别在凌晨跑完 TRUNCATE 就去睡觉，至少盯一眼 ls -lh 输出和 INFORMATION_SCHEMA 里的空间字段。
