应关闭会话级外键检查SET FOREIGN_KEY_CHECKS = 0，因其仅跳过当前连接的参照完整性校验而不删除约束，避免批量导入时因依赖顺序问题导致ERROR 1452中断；需成对恢复以防止长连接中遗留非法数据。
因为外键约束会强制校验每条插入数据的引用关系，而大批量导入时数据顺序往往无法满足依赖链要求，不关掉它根本插不进去。
外键检查如何让 LOAD DATA 或 INSERT 失败
MySQL 在执行 INSERT 或 LOAD DATA INFILE 时，默认对每行都做外键验证：子表字段值必须在父表中存在。但批量导入通常按表物理顺序导出（比如先导出 orders 表，再导出 users 表），而 orders 表里有 user_id 外键 —— 如果 users 表还没导入，所有 orders 插入都会报 ERROR 1452 (23000): Cannot add or update a child row...。
- 即使你手动拆分 SQL 文件，也很难保证所有依赖表一定先于被依赖表执行
- 触发器、级联操作、自增主键偏移等进一步打乱执行确定性
- 错误不是“卡住”，而是直接中断整个语句，
LOAD DATA不支持跳过单行失败
SET FOREIGN_KEY_CHECKS = 0 的实际作用范围
这个设置是**会话级（session-level）** 的，只影响当前连接，不影响其他客户端。它不删除外键定义，只是跳过运行时检查：
- 建表时写的
FOREIGN KEY依然存在，结构没变 -
SHOW CREATE TABLE输出不变，约束仍在元数据里 - 其他连接仍受约束保护，不会被你的操作波及
- 但如果你在同一个会话里后续执行
SELECT查数据，结果可能含“孤儿记录”——这点必须自己兜底校验
为什么不能只关 unique_checks 或 autocommit
单独关 unique_checks = 0 或设 autocommit = 0 解决不了外键问题：
-
unique_checks = 0只跳过唯一索引检查，对外键无影响 -
autocommit = 0只控制事务提交时机，不改变约束行为 - 真正要绕过的，是外键本身的参照完整性逻辑，只有
FOREIGN_KEY_CHECKS能动它 - 实践中常三者一起关：
SET FOREIGN_KEY_CHECKS = 0; SET unique_checks = 0; SET autocommit = 0;，但各自职责不能混
关完不恢复的后果比想象中更隐蔽
很多人记得关，却忘了开，或者以为脚本退出就自动恢复 —— 实际上不会：
- 会话断开后变量重置，但如果你用的是长连接池（如应用里的 MySQL 连接池），那个连接可能复用很久，
FOREIGN_KEY_CHECKS一直为 0 - 后续普通
INSERT看似成功，其实悄悄写入了非法数据，几天后才在报表或 JOIN 查询里暴露 -
SELECT @@FOREIGN_KEY_CHECKS;返回 0 是唯一可靠确认方式，别靠记忆或日志推测 - 最稳妥做法：把
SET FOREIGN_KEY_CHECKS = 1;写进同一段脚本末尾，和关操作成对出现，哪怕中间出错也要用EXIT或ROLLBACK保证它执行
