直接删会报错，因外键约束阻止删除被子表引用的父表记录；最常用方法是临时禁用外键检查：SET FOREIGN_KEY_CHECKS=0;执行删除;SET FOREIGN_KEY_CHECKS=1;
删除外键关联表数据时提示“Cannot delete or update a parent row”
这是 MySQL 的外键约束在起作用，说明你要删的记录被子表中的外键引用着。直接 DELETE 或 TRUNCATE 会失败，错误信息通常是：Cannot delete or update a parent row: a foreign key constraint fails。
最常用、最直接的绕过方式就是临时关闭外键检查：
-
SET FOREIGN_KEY_CHECKS=0;—— 立即禁用当前会话的外键校验 - 执行你的
DELETE FROM table_name WHERE ...或TRUNCATE table_name -
SET FOREIGN_KEY_CHECKS=1;—— 必须恢复，否则后续插入/更新可能破坏数据一致性
注意：FOREIGN_KEY_CHECKS 是会话级变量，只影响当前连接。如果你用的是连接池（比如 Django、Spring Boot），每次获取新连接都要重新设，不能依赖上一次设置。
想清空整张有外键的表，用 TRUNCATE 还是 DELETE
TRUNCATE 更快、不走事务、重置自增 ID，但它在有外键引用时默认报错；DELETE 走事务、保留自增 ID、可带 WHERE，但慢且可能锁表。
若你确定要清空整表且不想改外键定义，推荐组合使用：
SET FOREIGN_KEY_CHECKS=0;-
TRUNCATE table_name;（比DELETE FROM table_name效率高得多） SET FOREIGN_KEY_CHECKS=1;
别漏掉最后一步——没恢复的话，下一条 INSERT 可能因外键字段值非法而静默失败，排查起来非常隐蔽。
删除父表数据时自动清理子表，该用 ON DELETE CASCADE 还是手动关检查
两种思路本质不同：ON DELETE CASCADE 是声明式行为，属于外键定义的一部分；而 SET FOREIGN_KEY_CHECKS=0 是命令式绕过，不改变逻辑关系。
选哪个取决于场景：
- 日常业务中，父子记录天然应共存亡（如订单和订单项），就该在建表时加
ON DELETE CASCADE - 仅临时批量清理（如测试环境重置数据）、或需精确控制删除顺序（先删子再删父），才用
SET FOREIGN_KEY_CHECKS=0 - 误删生产数据后紧急回滚？关检查再删风险极高，优先考虑备份恢复或按外键路径逐层删
ON DELETE CASCADE 一旦设定，所有符合权限的 DELETE 都会触发级联，不可逆。上线前务必确认业务语义是否真需要它。
怎么查出某张表有哪些外键，以及它们的约束名
不先搞清外键名，就无法用 ALTER TABLE ... DROP FOREIGN KEY 删除约束。最可靠的方法是：
- 查建表语句：
SHOW CREATE TABLE table_name;—— 直接看到CONSTRAINT `xxx` FOREIGN KEY行 - 或者查系统表（InnoDB）：
SELECT CONSTRAINT_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'table_name' AND CONSTRAINT_SCHEMA = DATABASE();
注意：外键名可能是 MySQL 自动生成的（如 FK1C81D1738DA76），复制时别漏掉反引号；DROP FOREIGN KEY 后还要手动 DROP COLUMN 才算真正移除外键字段，这两步不能合并。
