MySQL报“Cannot delete or update a parent row”是因外键约束阻止删除，需先SET FOREIGN_KEY_CHECKS=0临时禁用（仅当前会话），执行删除后必须立即SET FOREIGN_KEY_CHECKS=1恢复，否则可能产生孤儿记录；该操作不持久、不跨连接，且禁用期间ON DELETE CASCADE等逻辑失效，务必配合事务与备份使用。
直接设 SET FOREIGN_KEY_CHECKS=0 就能禁用当前会话的外键检查，但必须配对恢复为 1，否则后续写入可能产生孤儿记录，且这个操作不跨连接、不持久、不推荐长期关闭。
为什么删父表数据会报 “Cannot delete or update a parent row”
这是 MySQL 在执行 DELETE FROM parent_table 或 TRUNCATE TABLE parent_table 时触发的外键保护机制。错误信息里明确提示：子表（比如 orders）中还有 user_id 指向你要删的 users.id。不是语法错，是约束拦住了。
常见误判是以为要先手动删子表，其实更高效的做法是临时绕过检查——前提是你知道自己在做什么、删的是谁、有没有级联逻辑被跳过。
-
ON DELETE CASCADE存在时，SET FOREIGN_KEY_CHECKS=0会让它彻底失效，不会自动删子记录 -
ON DELETE SET NULL同样不触发，字段值保持原样 - 哪怕只是
UPDATE parent_table SET id = ...，也会因外键引用失败，除非关检查或改子表同步
只在当前会话生效，别指望“一劳永逸”
FOREIGN_KEY_CHECKS 是会话级变量，SET FOREIGN_KEY_CHECKS=0 只影响你当前这一个连接。新开一个客户端、另一个应用连接、甚至同一程序重连后，它还是默认的 1。
有人试过 SET GLOBAL FOREIGN_KEY_CHECKS=0，但多数生产环境禁止普通用户改全局变量；即使有权限，也极不推荐——所有连接都跳过外键检查，风险不可控。
- 想验证当前值？运行
SELECT @@FOREIGN_KEY_CHECKS，返回0或1 - 脚本里用完必须加
SET FOREIGN_KEY_CHECKS=1，不能依赖连接断开自动恢复 - 如果用 Python 的
pymysql或mysql-connector-python，每次 execute 前单独 set，不要复用连接池里的旧连接状态
必须和事务配合，否则出错难回滚
禁用检查本身不支持回滚，SET FOREIGN_KEY_CHECKS=0 是立即生效的会话设置。一旦你删了父表数据，而子表没清理，再启检查也没法自动修复引用断裂。
真正安全的做法是把禁用、操作、恢复三步包进事务，并确保失败时能整体回滚：
START TRANSACTION; SET FOREIGN_KEY_CHECKS = 0; DELETE FROM users WHERE id = 123; -- 其他关联操作 SET FOREIGN_KEY_CHECKS = 1; COMMIT;
如果中间某步失败，直接 ROLLBACK 即可，FOREIGN_KEY_CHECKS 的变更仍保留在该会话中，但数据已还原。
- 注意：有些 ORM（如 Django）默认开启 autocommit，需显式
transaction.atomic()包裹 - mysqldump 导入时常用
--skip-foreign-key-checks参数，本质也是在每个会话开头执行SET FOREIGN_KEY_CHECKS=0 - 千万别在没备份的情况下，在生产库上跑
SET FOREIGN_KEY_CHECKS=0; TRUNCATE TABLE users;
最常被忽略的一点：关检查不等于“可以随便删”，它只是移除了 MySQL 的一道防护，而业务逻辑里的关联依赖依然存在。删之前得确认下游服务是否缓存了旧 ID、API 是否暴露了已被删的资源链接、ES 或 Redis 里有没有残留索引——外键只是数据库层的一环。
