foreign_key_checks=0仅对当前会话生效，禁用后该连接的dml跳过外键检查，但其他连接仍按默认值1校验；必须在同一连接中完成禁用→操作→启用全流程，否则新连接导入仍会报错。
FOREIGN_KEY_CHECKS=0 能绕过外键检查，但只在当前会话生效
这个变量不是全局开关，而是会话级设置。你在目标库执行 SET FOREIGN_KEY_CHECKS = 0; 后，仅该连接后续的 INSERT、UPDATE、DELETE 不校验外键；其他连接或新连接仍按默认值（1）执行检查。
常见错误是：用一个连接禁用后，再开新连接导入 SQL —— 新连接里外键检查照常触发，导致报错 Cannot add or update a child row: a foreign key constraint fails。
- 务必在同一个数据库连接中完成「禁用 → 导入 → 启用」全流程
- 若用脚本分批导入，每批都得先确认当前会话的
SELECT @@FOREIGN_KEY_CHECKS;值为 0 - 不依赖 dump 文件开头的
SET FOREIGN_KEY_CHECKS=0;—— 它可能被中间的USE other_db;或分段DELIMITER重置
金仓、达梦等兼容库的语法和作用域不同
迁移到金仓数据库时，对应语句是 SET foreign_key_checks = 0;（注意下划线、小写），且同样仅限当前会话；达梦数据库则不支持该变量，需改用 SET CONSTRAINTS ALL DEFERRED; 或直接删外键再重建。
关键差异点在于：MySQL 禁用后仍允许 REPLACE INTO 触发级联删除，而金仓在禁用状态下对 REPLACE INTO 的行为更保守，可能直接报错而非静默跳过。
- 跨库迁移前，先查目标库文档确认外键控制机制，别硬套 MySQL 写法
- 金仓中若用事务包裹批量操作，建议在
BEGIN后立即执行SET foreign_key_checks = 0; - 达梦迁移时，优先考虑用 DTS 工具自动处理外键依赖顺序，而非手动关检查
禁用后导入失败，恢复一致性比想象中麻烦
设为 0 后若中途出错中断，数据库不会自动回滚已插入的“孤儿数据”。这些数据在父表无对应主键，但外键约束又没生效，就变成脏数据。
你得人工定位：用 SELECT 查询 information_schema.KEY_COLUMN_USAGE 找出所有外键关系，再逐个写 LEFT JOIN 检查子表是否存在无效引用。
- 例如检查 orders 表的 customer_id 是否全在 customers 表存在：
SELECT o.* FROM orders o LEFT JOIN customers c ON o.customer_id = c.customer_id WHERE c.customer_id IS NULL; - 生产环境禁用前，建议先备份目标库，或至少导出外键定义：
SHOW CREATE TABLE table_name; - 禁用不是银弹——它解决的是导入速度问题，不是数据质量兜底方案
高并发场景下，物理外键本身可能是性能瓶颈
阿里订单系统实测显示，QPS 超 5k 时外键检查占延迟 70%。此时 FOREIGN_KEY_CHECKS = 0 只是临时缓解，真正要动的是架构：把强一致逻辑下沉到应用层，用 @Retryable + 显式校验 + 定时巡检替代数据库级约束。
迁移时若发现目标库是分布式或分库分表结构，强行保留物理外键会导致跨节点锁、死锁或无法生效，不如趁机重构为逻辑外键。
- 单体 MySQL 迁移到单机达梦/金仓，可谨慎使用
SET ... = 0 - 迁往分布式数据库（如 TiDB、OceanBase）或云原生架构，应主动移除外键定义，改由应用保障引用完整性
- 禁用外键后，
ON DELETE CASCADE等级联行为完全失效，相关业务逻辑必须同步调整
外键检查开关看似简单，但它撬动的是整个数据一致性模型。真正难的不是设成 0，而是清楚知道哪些数据可以不校验、哪些必须校验、以及出错后怎么快速兜住。
