应临时关闭外键检查并在同一会话内执行：先set foreign_key_checks = 0;，再导入sql，最后set foreign_key_checks = 1;，并手动验证孤儿数据及引擎、字符集等兼容性。
直接关 FOREIGN_KEY_CHECKS 就行，但必须在同一会话里“关→导入→开”三步闭环，否则无效。
为什么 mysqldump 导出的 SQL 在 8.0 导入时总卡在外键上？
不是数据错了，是表导出顺序和校验机制不匹配。5.7 默认按表名字母序导出（比如 orders 排在 users 前面），而 8.0 恢复时严格校验外键：插 orders 时发现 users 还没建，或 user_id = 100 这条记录根本没进来，立刻报 ERROR 1452 或 ERROR 1215。
常见错误现象：
- 导入中途停在某条
INSERT INTO orders，提示 “Cannot add or update a child row” - 用 DBeaver/Navicat 点击执行整个 SQL 文件，只看到前几行生效，后面全红
- SQL 文件开头写了
SET FOREIGN_KEY_CHECKS = 0;，但依然报错——因为 GUI 工具默认每条语句新建连接，该设置只对第一条生效
怎么安全跳过外键检查完成导入？
核心是确保“关校验→执行全部 SQL→开校验”都在同一个 MySQL 连接内完成。推荐两种实操方式：
- 命令行交互模式（最可控）：
mysql -u root -p db_name→ 手动输入：SET FOREIGN_KEY_CHECKS = 0;→SOURCE /path/to/dump.sql;→SET FOREIGN_KEY_CHECKS = 1; - 管道一次性送入（防断连）：
echo "SET FOREIGN_KEY_CHECKS = 0; $(cat dump.sql); SET FOREIGN_KEY_CHECKS = 1;" | mysql -u root -p db_name - 绝对不要在 SQL 文件里写
USE database_name;——它会触发隐式重连，让前面的SET失效 - 导入前先用
sed -i '/FOREIGN_KEY_CHECKS/d' dump.sql清掉文件里自带的同类语句，避免冲突
关了外键检查，就万事大吉了吗？
不是。这只是绕过了外键校验，其他约束照常生效：
-
PRIMARY KEY冲突、NOT NULL字段为空、字段类型不匹配（比如VARCHAR插数字）仍会报错 - 更危险的是：允许写入“孤儿数据”，例如
orders.user_id = 999，但users表里根本没有id = 999；恢复FOREIGN_KEY_CHECKS = 1后，这条记录依然合法存在 - 导入完成后必须立刻验证：
SELECT @@FOREIGN_KEY_CHECKS;返回值必须是1，再手动查孤儿记录：SELECT o.id FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL;
真正容易被忽略的是：关校验只是让导入跑通，不代表数据逻辑自洽。如果源库本身就有跨表引用断裂，或者父子表字符集、字段精度不一致（比如 INT(6) vs INT），跳过检查只会把问题延后到业务查询时静默失败。
