truncate不能直接用于线上大表清空，需绕过外键、权限、空间回收和业务连续性四大风险；其不释放磁盘空间因仅标记数据页可复用，须配合optimize table（需独立表空间且额外空间）；外键报错应按子表→父表顺序操作或改用delete；更推荐rename+异步drop；执行前须检查自增值、外键依赖、元数据锁及drop权限。
TRUNCATE 不能直接用于线上大表清空，除非你已绕过外键、权限、空间回收和业务连续性四大风险点。
为什么 TRUNCATE TABLE 大表后磁盘空间没变小
TRUNCATE 是 DDL 操作，它只把数据页标记为“可复用”，并不主动收缩 .ibd 文件。你执行 TRUNCATE TABLE big_log 后 ls -lh 看到的文件大小几乎不变——这不是命令失效，是 InnoDB 的空间管理机制决定的。
真正释放磁盘空间必须补上 OPTIMIZE TABLE big_log（MySQL 5.7+ 实际等价于 ALTER TABLE big_log FORCE），但要注意：
- 前提：确认
innodb_file_per_table = ON（MySQL 5.6+ 默认开启），否则表在系统表空间ibdata1里，OPTIMIZE无效 - 验证方式：
SELECT TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'big_log'，若CREATE_OPTIONS为空或含partitioned，一般表示独立表空间 -
OPTIMIZE TABLE需要额外磁盘空间（≈ 当前表大小），执行期间大量 IO，可能拖慢同实例其他查询
外键约束下 TRUNCATE 直接报错 ERROR 1701 怎么办
ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint 不是性能问题，是 DDL 层面被硬拦截。临时关外键（SET FOREIGN_KEY_CHECKS = 0）风险极高——它不区分会话，可能影响其他并发写入，且容易漏开/漏关。
更稳妥的做法是按依赖顺序操作：
- 查出引用关系：
SELECT TABLE_NAME, CONSTRAINT_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'parent_table' - 按“子表 → 父表”顺序生成
TRUNCATE语句（如先TRUNCATE TABLE order_items，再TRUNCATE TABLE orders） - 如果已有
ON DELETE CASCADE，其实用DELETE FROM parent_table更安全，只是慢；TRUNCATE在这种场景下反而绕不开约束检查
大表清空推荐用 RENAME + DROP 而不是 TRUNCATE + OPTIMIZE
如果你的目标不是“清空后继续用”，而是“彻底移除这张大表”，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 以上的日志表 - 避免了
TRUNCATE隐式提交导致的事务失控，也绕开了外键和权限校验的坑
执行前必须确认的三件事
别直接敲 TRUNCATE TABLE users。至少做这四步：
- 查当前自增值：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'users'—— 如果业务依赖当前AUTO_INCREMENT值（比如用作幂等 ID 或下游对账），重置就是硬伤 - 确认没活跃外键依赖：
SELECT CONSTRAINT_NAME, REFERENCED_TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'users' AND REFERENCED_TABLE_NAME IS NOT NULL - 检查元数据锁：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'users'，避免卡在Waiting for table metadata lock - 确认权限：
TRUNCATE需要DROP权限，不是DELETE权限；权限不足会报ERROR 1142 (42000): TRUNCATE command denied to user
最常被忽略的是自增重置和元数据锁——前者影响业务逻辑，后者让命令卡住却无提示，容易误判为“执行成功”。
