直接delete报错因外键默认restrict行为阻止操作；可临时禁用检查（set foreign_key_checks=0/1配对）、加on delete cascade级联或按依赖顺序手动清理。
直接 DELETE 报错 “foreign key constraint fails” 怎么办
这不是语法写错了，也不是权限不够，而是外键的默认行为在拦你。MySQL 用 RESTRICT，SQL Server 用 NO ACTION——只要子表里还有一行引用着你要删的父记录，DELETE 就会立刻失败，报错类似：Cannot delete or update a parent row 或 The DELETE statement conflicted with the REFERENCE constraint。
临时禁用外键检查（仅限当前会话）
这是最快见效的办法，但必须配对使用，漏掉第二步会埋雷：
-
SET FOREIGN_KEY_CHECKS = 0;—— MySQL 专用，只对当前连接生效 - 执行
DELETE FROM parent_table WHERE ...或TRUNCATE parent_table -
SET FOREIGN_KEY_CHECKS = 1;—— 这一步绝不能省！否则后续插入可能静默失败（比如往子表插了个不存在的user_id）
注意：TRUNCATE 在有外键时默认失败，必须配合 SET FOREIGN_KEY_CHECKS = 0 才能用；它比 DELETE 快，且重置自增 ID。
给外键加 ON DELETE CASCADE（适合生命周期绑定的场景）
如果业务逻辑明确“删父必删子”，比如删订单就该清空所有订单项，那就该改约束，而不是每次手动处理：
- 先查外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND REFERENCED_TABLE_NAME = 'parent_table'; - 删旧约束：
ALTER TABLE child_table DROP CONSTRAINT fk_name; - 重建带级联：
ALTER TABLE child_table ADD CONSTRAINT fk_name FOREIGN KEY (col) REFERENCES parent_table(id) ON DELETE CASCADE;
此后 DELETE FROM parent_table WHERE id = 123; 会自动清理所有下层关联记录。但要注意：级联不可逆、不走触发器、不发消息、也不留审计痕迹——2026 年起 MySQL 9.6+ 已把级联操作完整写入 Binlog，主从和 CDC 不再丢变更，但应用层依然感知不到。
手动按依赖顺序清理（最可控，但得自己理清关系链）
当你不确定是否真要删子数据，或只想删部分、保留部分时，必须自己控制顺序：
- 查依赖表：
SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'parent_table'; - 对每个子表，先删关联行：
DELETE FROM child_table WHERE parent_id IN (SELECT id FROM parent_table WHERE ...); - 最后删父表：
DELETE FROM parent_table WHERE ...;
多层嵌套（比如子表 → 孙表 → 曾孙表）时，得从最深一层开始倒着删；SQL Server 不支持 FOREIGN_KEY_CHECKS，所以这招是通用解法。容易被忽略的是：跨 schema 的外键必须写全名，如 REFERENCES dbo.users(id)，漏 schema 会建约束失败。
