能用，但仅限明确后果的临时场景：批量导入、清空重建、死锁修复；禁用后所有DML跳过外键检查，必须配对恢复，否则导致脏数据。
MySQL 里 SET FOREIGN_KEY_CHECKS=0 到底能不能用
能用，但只该在明确知道后果的前提下临时关闭——它不是“绕过报错”的万能开关，而是直接禁用整张表的外键约束校验。一旦关了，insert、update、delete 都不会触发外键检查，哪怕插入一个根本不存在的 user_id 也不会报错。
什么时候必须关、什么时候绝对不能关
必须关的典型场景：批量导入历史数据、清空并重建关联表、修复因外键阻塞导致的死锁；不能关的场景：线上业务查询、日常增删改、任何涉及用户输入或不确定数据来源的操作。
- 导入 SQL 文件前，如果文件里包含跨表插入顺序混乱（比如先插
order再插user），关掉可避免报错Cannot add or update a child row: a foreign key constraint fails - 执行
TRUNCATE TABLE某个被外键引用的父表时，MySQL 会直接拒绝，此时必须先SET FOREIGN_KEY_CHECKS=0，再TRUNCATE，完事立刻SET FOREIGN_KEY_CHECKS=1 - 在存储过程或事务里关了但没恢复，后续所有操作都失去外键保护，极易写入脏数据
SET FOREIGN_KEY_CHECKS 的作用范围和坑点
它只对当前会话生效，不是全局设置，所以不同连接之间互不影响。但正因为“只影响当前会话”，很多人误以为“开了事务就安全”，其实不然：只要会话还连着，哪怕事务回滚了，FOREIGN_KEY_CHECKS 依然保持你设的值。
- 执行
SET FOREIGN_KEY_CHECKS=0后，务必配对执行SET FOREIGN_KEY_CHECKS=1，别依赖连接断开自动恢复 - 某些 ORM（如 Django）在连接池复用时可能拿到一个
FOREIGN_KEY_CHECKS=0的旧连接，导致后续正常操作也跳过校验 -
mysqldump默认导出时会加SET FOREIGN_KEY_CHECKS=0，但这是为了 dump 本身能成功，不是建议你在业务里照搬
替代方案比硬关更稳妥
真正想“忽略报错”而不是“禁用约束”，优先考虑调整 SQL 逻辑或临时解除约束，而非全局关检查。
- 用
DELETE FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table)清理孤儿数据，而不是关检查后硬删 - 建表时用
ON DELETE CASCADE或ON DELETE SET NULL，让数据库自己处理级联，避免手动关检查 - 需要临时绕过？用
ALTER TABLE table_name DROP FOREIGN KEY fk_name删除特定外键，操作完再ADD FOREIGN KEY加回去，比关全局检查更精准
最常被忽略的一点：关检查不等于数据就合法了。它只是把校验这道门拆了，门后的问题（比如缺失关联记录、ID 类型不匹配）依然存在，只是延迟到应用层或下游查询时才暴露。
