最常见原因是权限不足，truncate需drop权限而非仅delete权限；其次是外键约束拦截，需临时禁用或删除外键；再者是元数据锁冲突，常因长事务或sleep会话阻塞；最后是auto_increment重置导致业务查不到旧id。
用户执行TRUNCATE报错“Access denied”
最常见原因是权限不足。TRUNCATE TABLE本质是DROP + CREATE，需要DROP权限，而不仅是DELETE权限。即使用户有SELECT、INSERT、UPDATE，缺DROP也会直接拒绝。
检查方式：SHOW GRANTS FOR 'username'@'host';，确认输出中包含GRANT DROP ON `db_name`.`table_name`或更宽泛的GRANT DROP ON *.*。若无，需用高权限账号执行：GRANT DROP ON database_name.table_name TO 'username'@'host'; FLUSH PRIVILEGES;
执行TRUNCATE提示“Cannot truncate a table referenced in a foreign key constraint”
这是外键约束拦截，不是权限问题。MySQL在检测到该表被其他表的FOREIGN KEY引用时，会主动拒绝TRUNCATE（哪怕只是被引用，自身没定义外键）。
临时绕过方法（仅限开发/测试环境）：SET FOREIGN_KEY_CHECKS = 0;TRUNCATE TABLE target_table;SET FOREIGN_KEY_CHECKS = 1;
⚠️ 注意：该设置是会话级，但必须确保当前会话未开启事务（否则SET可能被忽略），且下游应用能容忍外键约束短暂失效。
生产环境更稳妥的做法：
- 先ALTER TABLE referencing_table DROP FOREIGN KEY fk_name;
- 执行TRUNCATE
- 再ALTER TABLE referencing_table ADD CONSTRAINT ...
避免全局关外键，降低误操作风险。
show processlist看到TRUNCATE卡在“System lock”状态
这不是用户权限问题，而是元数据锁（MDL）冲突。当目标表正被其他连接执行SELECT FOR UPDATE、长时间查询、或处于活跃事务中时，TRUNCATE无法获取独占MDL写锁，就会挂起在System lock。
排查步骤：
- 查看阻塞源头：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 'table_name';
- 关联等待关系：SELECT * FROM performance_schema.threads t JOIN performance_schema.metadata_locks m ON t.thread_id = m.owner_thread_id WHERE m.OBJECT_NAME = 'table_name';
- 检查长事务：SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5;
关键点：kill掉持有MDL读锁的会话（尤其是Command: Sleep但Time很长的），比直接kill TRUNCATE更有效——后者常卡在killed状态不退出，反而加剧夯住。
TRUNCATE后业务报“not found”，但语句明明执行成功了
这通常不是执行失败，而是副作用被忽略：TRUNCATE会重置AUTO_INCREMENT值为1。如果前端缓存了旧ID（比如用户刚编辑过ID=12345的记录），清空后新插入数据从ID=1开始，再用12345去查就必然not found。
验证方式：SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='table_name';，对比截断前后是否归零。
业务侧应对建议：
- 避免在非幂等场景下使用TRUNCATE（如测试环境批量重跑数据可接受，线上配置表慎用）
- 若必须清空且保留ID连续性，改用DELETE FROM table_name;，并确认没WHERE条件
- 清空后手动重设自增值：ALTER TABLE table_name AUTO_INCREMENT = N;（N为期望起点）
真正卡住的往往不是权限校验那一秒，而是System lock背后那个没人关注的Sleep会话，或者FOREIGN_KEY_CHECKS = 0之后忘记恢复导致后续DML异常。这些点不写进监控，就永远在出事时才被看见。
