导出前必须勾选“Disable foreign key checks”并验证SQL文件头尾是否含SET FOREIGN_KEY_CHECKS=0;和=1;，否则导入会因依赖顺序报错；Quick模式不支持该选项，须用Custom模式并手动启用。
导出前必须确保外键检查被禁用，否则导入时会因依赖顺序失败；phpMyAdmin 默认生成的 SQL 开头含 SET FOREIGN_KEY_CHECKS=0;，但大型库或自定义配置下可能缺失，必须手动验证。
导出时必须勾选“Disable foreign key checks”
即使你看到导出设置里有“添加 DROP 语句”，也不代表外键约束会被跳过——DROP 只删表，不解决插入时的依赖校验。导入阶段 MySQL 仍会按语句顺序执行 INSERT，若先插子表、后建父表，就会报错 Cannot add or update a child row: a foreign key constraint fails。
- Custom 导出模式下，在「数据」区域滚动到底部，明确勾选
Disable foreign key checks - 该选项对应生成 SQL 文件开头的
SET FOREIGN_KEY_CHECKS=0;和结尾的SET FOREIGN_KEY_CHECKS=1; - 不要依赖“Quick”模式——它不提供该选项，且默认不导出视图/存储过程等逻辑对象，复杂数据库恢复后功能不全
导出后必须验证 SET FOREIGN_KEY_CHECKS 是否真实存在
phpMyAdmin 导出中断不会报错，只给一个残缺文件。尤其在超 100MB 的库上，常见现象是文件末尾突然截断，SET FOREIGN_KEY_CHECKS=1; 消失，甚至整个外键禁用语句都没写进去。
- 用文本编辑器打开导出的
.sql文件，搜索前 20 行是否有SET FOREIGN_KEY_CHECKS=0; - 再搜文件末尾附近是否有
SET FOREIGN_KEY_CHECKS=1;（不是中间某处） - 如果只找到前者、没后者，说明导出被截断；如果两者都无，说明该选项根本没生效，需重导并确认勾选
复合外键 + 循环依赖时，仅靠 Disable 不够
当 A 表外键指向 B，B 表又外键指向 A（比如用户与默认地址互引），即使禁用了外键检查，导入后启用约束时仍会批量校验失败。这是因为 SET FOREIGN_KEY_CHECKS=1; 是最后统一触发的，而此时数据已全部写入，校验必然失败。
- 这类场景下，导出文件必须包含
SET CONSTRAINTS ALL DEFERRED;或等效逻辑（phpMyAdmin 不直接支持，需手动在 SQL 文件开头插入） - 更稳妥的做法：改用命令行
mysqldump --skip-triggers --no-autocommit --single-transaction，它能更好处理事务边界和约束延迟 - 如果坚持用 phpMyAdmin，导入前先在目标库手动执行
SET FOREIGN_KEY_CHECKS=0;，导入完成后再运行SET FOREIGN_KEY_CHECKS=1;——但这绕过了文件自带的保护机制，需自行担责
最容易被忽略的是：外键约束是否真被导出。phpMyAdmin 不显示“外键定义是否完整”，只管生成语句。导出后应打开文件搜 FOREIGN KEY，确认每个关联字段都出现在 ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY (...) REFERENCES ... 中，而不是仅靠注释或缺失定义硬凑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
