truncate不产生碎片但不收缩.ibd文件，需optimize table才能物理缩小；外键、权限、事务限制多，大表清空推荐rename+drop替代。
TRUNCATE本身不产生碎片，但也不会自动收缩.ibd文件
TRUNCATE TABLE 是直接释放数据页并重建表结构的 DDL 操作，它不会像 DELETE 那样留下空闲页或索引碎片——所以“清空时不产生碎片”这点是成立的。但关键误区在于：很多人执行完 TRUNCATE TABLE t1; 就以为磁盘空间回来了，其实 .ibd 文件大小几乎不变，只是内部页被标记为“可复用”。这不算碎片，但会误导你对实际磁盘占用的判断。
真正收缩.ibd必须加OPTIMIZE TABLE（仅限独立表空间）
要让 .ibd 文件物理变小，必须补上 OPTIMIZE TABLE t1;。它在 InnoDB 中实际等价于 ALTER TABLE t1 FORCE，会重建聚簇索引和二级索引，丢弃所有空页，并写入紧凑格式。
- 前提：确认开启了
innodb_file_per_table = ON（MySQL 5.6+ 默认开启），否则表在系统表空间ibdata1里，OPTIMIZE无效 - 验证方式：
SELECT TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't1';—— 若CREATE_OPTIONS为空或含partitioned，一般表示独立表空间 - 注意：
OPTIMIZE TABLE需要额外磁盘空间（≈ 当前表大小），执行期间会读写大量 IO，可能拖慢同实例其他查询
外键、权限、事务这些地方最容易卡住
线上执行前不检查依赖，TRUNCATE TABLE 很可能直接报错退出，白忙活一场。
- 外键报错：
Cannot truncate a table referenced in a foreign key constraint——FOREIGN_KEY_CHECKS = 0对 TRUNCATE 无效，必须先删外键或改用DELETE分批 - 权限不足：
ERROR 1142 (42000): TRUNCATE command denied to user—— 它需要DROP权限，不是DELETE权限 - 事务内执行：哪怕包在
BEGIN里，TRUNCATE也会隐式提交，ROLLBACK无效 - 自增 ID 重置：如果业务依赖当前
AUTO_INCREMENT值（比如用作幂等 ID 或下游对账），TRUNCATE 后从 1 开始就是硬伤
大表清空更稳妥的替代路径：RENAME + DROP
如果你的目标不是“清空后继续用”，而是“彻底移除这张大表”，RENAME TABLE big_log TO big_log_to_drop; 再异步 DROP TABLE big_log_to_drop; 更安全高效。
-
RENAME是原子 DDL，毫秒完成，业务最多收到一次Table doesn't exist -
DROP由后台线程异步清理，不阻塞主库响应；即使卡在 IO 上，也只是释放延迟，不影响可用性 - 跳过了
TRUNCATE + OPTIMIZE的双阶段锁和空间压力，尤其适合几十 GB 以上的日志表
