MySQL 8.0+不支持WITH RECURSIVE直接配合DELETE操作，必须先用递归CTE或存储过程将待删ID存入临时表，再通过JOIN或IN子查询执行删除；外键默认RESTRICT，需手动遍历依赖链或显式添加ON DELETE CASCADE，且须注意跨schema限制、间接引用遗漏及SET FOREIGN_KEY_CHECKS=0导致孤儿数据风险。
不能直接在存储过程中用递归 CTE 删除带外键的层级数据——MySQL 8.0+ 不支持 WITH RECURSIVE 直接跟 DELETE，且外键约束会拦住级联路径。
MySQL 存储过程里递归删树形结构必须绕开 CTE + DELETE 组合
很多人写 WITH RECURSIVE t AS (...) DELETE FROM tree WHERE id IN (SELECT id FROM t)，这在 PostgreSQL 可行，但在 MySQL 报错：ERROR 1288: The target table tree of the DELETE is not updatable。MySQL 的 DELETE ... USING 语法不接受递归 CTE 作为子查询源，也不允许 CTE 后紧跟 DML。
- 必须先把递归查出的 ID 集合存进临时表（如
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)） - 再用
DELETE FROM tree WHERE id IN (SELECT id FROM tmp_ids)删除主表 - 但注意：临时表只在当前连接有效，存储过程里要确保没并发冲突
- 若层级深、ID 多，
IN (SELECT ...)可能变慢，可改用JOIN：DELETE t FROM tree t JOIN tmp_ids tmp ON t.id = tmp.id
外键约束不自动递归，得靠存储过程手动遍历依赖链
即使你清掉了主表所有子节点，只要某个子表的记录还被更下游的表外键引用着，删除就会卡在 Cannot delete or update a parent row。MySQL 的外键默认是 RESTRICT，不会因为你删了上层就自动清理下下层。
- 必须从目标表出发，用
INFORMATION_SCHEMA.KEY_COLUMN_USAGE查所有引用它的外键：SELECT TABLE_NAME, COLUMN_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table' AND REFERENCED_TABLE_SCHEMA = DATABASE() - 对每个查到的子表，拼出
SELECT GROUP_CONCAT(id)获取待删 ID 列表，再递归调用自身（需开启max_sp_recursion_depth） - 注意：MySQL 默认
max_sp_recursion_depth = 0，得先设SET @@SESSION.max_sp_recursion_depth = 25 - 游标里不能直接执行动态 SQL，要用
PREPARE/EXECUTE，且每次只能查一列值，GROUP_CONCAT是唯一可靠取多 ID 的方式
ON DELETE CASCADE 不是万能解，已有表加它要三步走
如果真想靠数据库自动递归删，唯一靠谱路是给所有外键加 ON DELETE CASCADE。但这不是 ALTER 一句就能加上的事。
- 先查外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id' - 再删旧约束：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id - 最后重建：
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE - 关键限制：MySQL 不支持跨 schema 级联；被引用列不能是
timestamp；子表若分区，级联可能失效或极慢 - 级联删不触发触发器、不写审计日志——应用层完全感知不到，线上慎用
最易漏掉的检查点：根节点是否被非直接子表引用
递归 CTE 或存储过程只扫一层外键依赖，但真实业务里常有“间接引用”：A 表 → B 表 → C 表，而你要删 A 中某条记录，C 表其实也通过 B 表锁住了它。这种链式依赖不会被单层 KEY_COLUMN_USAGE 查全。
- 必须人工确认业务模型，或用脚本跑完整依赖图：
SELECT DISTINCT k1.TABLE_NAME, k2.TABLE_NAME AS ref_table FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE k1 JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE k2 ON k1.TABLE_NAME = k2.REFERENCED_TABLE_NAME WHERE k1.REFERENCED_TABLE_NAME = 'target_table' - 哪怕只差一层，漏掉就会在删到某张表时突然报
FOREIGN KEY constraint failed - 别用
SET FOREIGN_KEY_CHECKS = 0临时关约束——关了之后级联失效，只删主表，子表留孤儿数据，后续查不出问题但逻辑已坏
