正常。truncate table在innodb中仅清空数据页并重建表结构，不释放磁盘空间给操作系统，.ibd文件大小不变但内部页被标记为“可复用”；真正收缩需配合optimize table或alter table engine=innodb（前提是innodb_file_per_table=on）。
TRUNCATE TABLE 后 .ibd 文件大小没变，正常吗？
完全正常。InnoDB 的 TRUNCATE TABLE 会清空数据页并重建表结构，但默认不会把磁盘空间还给操作系统——.ibd 文件大小纹丝不动，只是内部页被标记为“可复用”。这不是失败，而是 InnoDB 空间管理机制决定的。
验证是否真执行成功：
- 查 error log 确认没报错
- 运行 SELECT COUNT(*) FROM table_name; 应返回 0
- 检查 SELECT DATA_LENGTH, DATA_FREE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'table_name';：若 DATA_LENGTH 接近 0 且 DATA_FREE 显著上升，说明已清空但未收缩
真正释放磁盘空间必须加 OPTIMIZE TABLE
OPTIMIZE TABLE 在 InnoDB 中等价于 ALTER TABLE ... FORCE，它会重建聚簇索引和所有二级索引，丢弃空页，并物理重写紧凑的 .ibd 文件。
但要注意前提条件：
- 必须开启 innodb_file_per_table = ON（MySQL 5.6+ 默认开启）
- 执行前确认表不在系统表空间（SELECT CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'table_name'; 返回含 partitioned 或为空才安全）
- 需要额外磁盘空间 ≈ 当前表大小，否则可能因 /tmp 或 innodb_tmpdir 爆满而中断
TRUNCATE 失败的三个高频原因
命令跑不通，八成卡在这三处：
- 外键被引用：ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint —— SET FOREIGN_KEY_CHECKS = 0 对 TRUNCATE 无效，必须先 DROP FOREIGN KEY 或改用分批 DELETE
- 权限不足：ERROR 1142 (42000): TRUNCATE command denied to user —— 需要 DROP 权限，不是 DELETE 权限
- 被 MDL 锁阻塞：SHOW PROCESSLIST 中状态为 Waiting for table metadata lock —— 检查是否有长事务正在查询该表，或有未关闭的连接
大表清空别硬刚 TRUNCATE + OPTIMIZE
几十 GB 以上的日志表、历史归档表，走 TRUNCATE 再 OPTIMIZE 是高风险组合：双阶段锁、IO 峰值、长时间阻塞、磁盘空间翻倍需求。
更稳妥的替代路径：
- RENAME TABLE big_log TO big_log_to_drop;（毫秒级原子操作）
- 异步执行 DROP TABLE big_log_to_drop;（后台线程清理，不阻塞主库）
- 如果业务允许彻底移除，这条路径跳过空间回收时机博弈，也避开 AUTO_INCREMENT 重置问题
真正麻烦的从来不是“怎么删”，而是删完要不要立刻还空间、能不能承受锁与 IO 压力、下游是否依赖自增值——这些决策点比命令本身更关键。
