MySQL中自引用外键表无法直接TRUNCATE，因TRUNCATE是DDL且MySQL严格校验自引用约束；SET FOREIGN_KEY_CHECKS=0无效，须改用递归DELETE或重建ON DELETE CASCADE外键。
MySQL 中自引用外键表不能直接 TRUNCATE
自引用外键（比如 parent_id 指向同一张表的 id）会让 TRUNCATE TABLE 直接失败，报错：ERROR 1701 (42000): Cannot truncate a table referenced in a foreign key constraint。这不是权限或语法问题，而是 MySQL 在 TRUNCATE 前会检查所有外键约束——哪怕约束是“自己引用自己”，它也拦。
原因在于 TRUNCATE 是 DDL，不走事务引擎的行级逻辑，无法做引用完整性校验的绕过；而自引用意味着该表既是父表又是子表，约束无法被临时“忽略”而不破坏语义。
- 别试
SET FOREIGN_KEY_CHECKS = 0配合TRUNCATE—— 这招对跨表外键有效，但对自引用无效，MySQL 仍会拒绝 -
DELETE FROM table_name可以执行，但若表有大量层级数据，可能因递归依赖触发锁等待或超时（尤其在高并发写入场景） - 真正安全的前提是：先确认是否真要物理清空。很多所谓“清空层级表”的需求，其实更适合用软删除（加
is_deleted字段）或重置 ID 范围（如只删created_at < '2025-01-01'的子树）
用递归 CTE 查出完整子树再批量 DELETE
MySQL 8.0+ 支持 WITH RECURSIVE，但注意：它不能直接跟 DELETE，必须分两步——先查 ID，再删。
假设表叫 org_nodes，结构为 (id, name, parent_id)，你想清空整棵树（从根节点开始）：
WITH RECURSIVE tree AS ( SELECT id FROM org_nodes WHERE id = 1 -- 根节点 UNION ALL SELECT n.id FROM org_nodes n INNER JOIN tree t ON n.parent_id = t.id ) SELECT id FROM tree;
把结果存进临时表，再删：
CREATE TEMPORARY TABLE tmp_to_delete AS (
WITH RECURSIVE tree AS (
SELECT id FROM org_nodes WHERE id = 1
UNION ALL
SELECT n.id FROM org_nodes n INNER JOIN tree t ON n.parent_id = t.id
)
SELECT id FROM tree
);
DELETE n FROM org_nodes n INNER JOIN tmp_to_delete t ON n.id = t.id;- 临时表名不能重复，存储过程中建议加连接唯一标识（如
CONCAT('tmp_del_', CONNECTION_ID())） - 避免用
IN (SELECT ...)，大结果集下性能陡降；JOIN方式更稳定 - 如果根节点不唯一（即多棵树），需把初始查询改成
WHERE parent_id IS NULL或其他判定条件
自引用表的外键必须显式设 ON DELETE CASCADE 才能自动级联
默认的自引用外键是 RESTRICT，删一个节点不会自动删其所有子孙。想让它“删父带子”，必须重建外键并加上 ON DELETE CASCADE：
先查原约束名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'org_nodes' AND REFERENCED_TABLE_NAME = 'org_nodes';
然后删旧建新（注意字段类型和 NULL 性必须严格一致）：
ALTER TABLE org_nodes DROP FOREIGN KEY fk_org_parent; ALTER TABLE org_nodes ADD CONSTRAINT fk_org_parent FOREIGN KEY (parent_id) REFERENCES org_nodes(id) ON DELETE CASCADE;
- 加完之后，
DELETE FROM org_nodes WHERE id = 1就会递归删掉整个子树 - 但注意：级联过程不可中断、不走触发器、不记录应用层日志；生产环境启用前务必在测试库验证影响行数
- 已有数据无需改动，约束只作用于后续的 DML 操作
清空前必须检查循环引用风险
自引用结构最容易出现人为制造的循环（比如 A → B → C → A），这种数据会让递归 CTE 死循环，直到达到 cte_max_recursion_depth（默认 1000）后报错：ERROR 3636: Recursive query aborted after 1000 iterations。
上线前应主动扫描：
SELECT id, parent_id FROM org_nodes WHERE parent_id IN (SELECT id FROM org_nodes) AND id = parent_id; -- 自环（直接指向自己） -- 或更通用的检测（需配合存储过程或应用层遍历）
- MySQL 原生不支持在单条 SQL 中检测任意长度循环，只能靠业务规则约束（如禁止
parent_id = id）或应用层插入时校验 - 如果已存在循环，递归删除会失败，必须人工定位并修复数据（比如把某条
parent_id设为NULL） - 临时禁用外键检查（
SET FOREIGN_KEY_CHECKS = 0）对解决循环无帮助，它只跳过约束检查，不解决逻辑死循环
实际操作中最容易被忽略的点是：自引用外键的 ON DELETE CASCADE 一旦启用，就再也无法通过普通 DELETE 语句“只删当前节点、保留子节点”——因为约束强制了行为。所以是否开启，本质是数据模型层面的取舍，不是运维开关。
