根本原因是导入破坏外键依赖链，需按父表→子表顺序导入或临时禁用外键检查并确保会话持续生效；误传的--skip-foreign-key-checks不存在，正确做法是手动加SET FOREIGN_KEY_CHECKS=0/1且避免隐式重连。
导入时 ERROR 1452 或 ERROR 1215 总是中断，根本原因不是数据错
这类报错（Cannot add or update a child row 或 Cannot add foreign key constraint）90% 不是数据本身有问题，而是导入过程破坏了外键依赖链。MySQL 要求：父表必须先建好、父记录必须先插入，子表才能引用。而默认导出顺序（按表名字母序）和 GUI 工具的执行机制天然违背这点。
mysqldump 导出时加 --skip-foreign-key-checks 是伪命题
mysqldump 命令根本没有 --skip-foreign-key-checks 这个参数——这是高频误传。真正有效的是：
- 导出时不带建表语句：
mysqldump --no-create-info --skip-triggers --set-gtid-purged=OFF -u user -p db_name table1 table2 > data.sql - 手动在
data.sql开头插入SET FOREIGN_KEY_CHECKS = 0;，结尾插入SET FOREIGN_KEY_CHECKS = 1; - 若导出含
CREATE TABLE，必须确认所有表都显式指定ENGINE=InnoDB；MyISAM 表即使写了外键也会静默失效
Navicat / DBeaver 里写 SET FOREIGN_KEY_CHECKS = 0; 基本白搭
GUI 工具默认每批 SQL 新建连接，SET 只在第一个语句的会话里生效，后续 INSERT 全部跑在新连接上，开关仍是默认的 1。真正能生效的只有两种方式：
- 命令行交互式执行：
mysql -u root -p database_name→ 手动输入SET FOREIGN_KEY_CHECKS = 0;→SOURCE /path/to/data.sql;→SET FOREIGN_KEY_CHECKS = 1; - 流式拼接执行：
echo "SET FOREIGN_KEY_CHECKS = 0; $(cat data.sql); SET FOREIGN_KEY_CHECKS = 1;" | mysql -u root -p database_name - 绝对不要在 SQL 文件里写
USE database_name;——它会触发隐式重连，让前面的SET失效
比关检查更稳的三种实操路径
禁用外键只是绕过问题，不是解决问题。数据不一致隐患会延后爆发：
- 按依赖顺序导入：用
SELECT table_name, referenced_table_name FROM information_schema.KEY_COLUMN_USAGE WHERE constraint_schema = 'db_name' AND referenced_table_name IS NOT NULL;拉出引用关系图，先导入被引用的表（如users），再导入引用它的表（如orders） - 预查脏数据：
SELECT user_id FROM orders WHERE user_id NOT IN (SELECT id FROM users);，删掉或补全缺失的父记录 - 建表阶段留余地：先建子表但不加外键，等数据导入完成、确认无误后，再
ALTER TABLE orders ADD FOREIGN KEY (user_id) REFERENCES users(id);
最容易被忽略的点：关了 FOREIGN_KEY_CHECKS 却没恢复，或者恢复前就断开了连接——后续所有写入都会跳过校验，脏数据会无声累积，直到某次业务查询崩掉才暴露。
