truncate table快且不能回滚，因其是ddl操作，直接丢弃数据页并重建表结构，不写行级日志、不进undo log、不触发触发器，执行即隐式提交，故rollback无效；外键约束（如error 1701）和权限（需drop权限）会阻止执行，清空后磁盘空间不立即释放，需配合optimize table收缩.ibd文件。
TRUNCATE TABLE 为什么快，但不能回滚
因为 TRUNCATE TABLE 是 DDL 操作，不是逐行删数据，而是直接丢弃旧的数据页、重建空表结构。它不写行级 binlog（默认）、不进 undo log、不触发 DELETE 触发器——所以快，但也意味着一旦执行，ROLLBACK 完全无效，事务里也拦不住。
常见错误现象：ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint —— 这不是性能问题，是外键依赖阻止了 DDL 的“重建”逻辑。
- 必须有
DROP权限（不只是DELETE权限） - 不能在事务中靠
ROLLBACK撤销，哪怕你刚BEGIN就执行了 - 如果表被视图或存储过程强引用（如索引视图），部分版本会直接报错
清空大表后磁盘空间没变小？这是正常现象
TRUNCATE TABLE 只把数据页标记为“可复用”，不会主动收缩 .ibd 文件大小。你 ls -lh 看到的文件体积几乎不变，不是命令失效，是 InnoDB 的空间管理机制决定的。
真正释放磁盘空间要分两步：
- 先执行
TRUNCATE TABLE tbl_name - 再执行
OPTIMIZE TABLE tbl_name（MySQL 5.7+ 实际等价于ALTER TABLE tbl_name FORCE）
注意：OPTIMIZE TABLE 会锁表（即使启用了 online DDL，也有短暂全局锁），且需要额外磁盘空间（重建期间新旧表并存）。生产环境务必避开高峰。
外键约束下怎么安全级联清空多张表
直接对父表（如 users）执行 TRUNCATE TABLE 会被外键拦住，但又不想手动 SET FOREIGN_KEY_CHECKS=0（易漏关、风险高）。更稳妥的做法是按依赖顺序从子表开始清空。
实操建议：
- 查出依赖关系：
SELECT TABLE_NAME, CONSTRAINT_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'parent_table'; - 按“被引用表 → 引用表”逆序生成
TRUNCATE语句（即先order_items，再orders，最后users） - 不要用存储过程自动禁用外键——临时关闭可能影响其他并发写入
如果表间有 ON DELETE CASCADE，其实用 DELETE FROM parent_table 更安全，只是慢；TRUNCATE 在这种场景下反而绕不开约束检查。
哪些配置会影响 TRUNCATE + OPTIMIZE 的实际效果
两个关键变量必须为 ON，否则 OPTIMIZE TABLE 不会缩小 .ibd 文件：
-
innodb_file_per_table：必须开启（MySQL 5.6+ 默认 ON），确保每张表独占一个.ibd文件 -
innodb_file_format已废弃，但对应行格式需支持（如COMPACT或DYNAMIC）；若仍用老旧的REDUNDANT，OPTIMIZE可能无效
验证方式：SHOW VARIABLES LIKE 'innodb_file_per_table';。如果返回 OFF，TRUNCATE 后的空间只能被同库其他表复用，无法返还给操作系统。
真正难的是权衡：想快就用 TRUNCATE，想缩盘就得加 OPTIMIZE 或切换表，而后者需要双倍磁盘空间和精确的原子切换时机——这点容易被忽略，直到 Disk full 报错才反应过来。
