必须在SQL文件开头加SET FOREIGN_KEY_CHECKS = 0;、末尾加SET FOREIGN_KEY_CHECKS = 1;，且确保所有表为InnoDB引擎、关联字段类型严格一致，导入后需手动验证级联是否生效。
导入前必须手动开关外键检查
phpMyAdmin 5.1 不会自动处理外键依赖顺序，直接导入含 FOREIGN KEY 的 SQL 文件大概率失败，报错类似 cannot add or update a child row: a foreign key constraint fails。根本原因是它逐行执行语句，而子表建表或插入若早于父表，约束就找不到引用目标。
解决办法只有一条硬规则：在 SQL 文件最开头加独立一行 SET FOREIGN_KEY_CHECKS = 0;，结尾加独立一行 SET FOREIGN_KEY_CHECKS = 1;。这两行不能和 CREATE DATABASE 或 CREATE TABLE 写在同一行，也不能被注释包裹（除非是 mysqldump 自带的 /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */ 这类条件注释，它等效）。
常见误区：
-
mysqldump --skip-foreign-key-checks参数无效——它只影响 dump 过程，不往输出里写开关语句 - 误以为 phpMyAdmin 界面“导入设置”里勾选“忽略错误”就能绕过——它不跳过外键校验，只跳过语法或重复键错误
确认所有表都用 InnoDB 引擎
外键级联（ON DELETE CASCADE、ON UPDATE CASCADE）只在 InnoDB 下生效，MyISAM 表即使语法通过也不会真正建立约束。phpMyAdmin 导入成功后不会提示引擎不匹配，但后续 DELETE 或 UPDATE 父表时，子表数据不会联动。
立即学习“PHP免费学习笔记（深入）”；
验证方式：
- 导入完成后，执行
SHOW CREATE TABLE `table_name`;，确认输出中明确包含ENGINE=InnoDB - 不要依赖右侧“关系视图”里的锁图标——它只是界面配置缓存，不代表 MySQL 实际加载了约束
- 运行
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db_name';批量检查所有表引擎
字段类型与长度必须严格一致
即使开了外键检查、用了 InnoDB，只要主表和子表的关联字段类型不完全一致，级联操作照样静默失效。比如主表 id INT UNSIGNED，子表 user_id INT（缺 UNSIGNED），MySQL 会接受建表，但 ON DELETE CASCADE 不触发，且只报 warning，phpMyAdmin 界面完全不显示。
关键比对项：
- 整数类型：是否都带
UNSIGNED，是否同为TINYINT/INT/BIGINT - 字符串类型：是否同为
VARCHAR(255)，字符集是否都是utf8mb4（推荐），排序规则是否兼容（如utf8mb4_0900_ai_ci和utf8mb4_unicode_ci可互引，但utf8_general_ci与utf8mb4_bin不行） - 时间类型：是否都用
DATETIME或都用TIMESTAMP，精度是否一致（如DATETIME(3)不能引用DATETIME(6)）
导入后必须手动验证级联是否真生效
执行完导入、看到“导入成功”消息，不代表级联逻辑已就位。最容易被跳过的一步是验证——因为失败时没有明显报错，只有行为异常。
快速验证方法：
- 找一对有
ON DELETE CASCADE的父子表，手动DELETE父表某条记录，立刻查子表对应记录是否消失 - 执行
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db_name' AND REFERENCED_TABLE_NAME IS NOT NULL;，确认DELETE_RULE和UPDATE_RULE列值是CASCADE，不是RESTRICT或空 - 注意 MySQL 9.6.0+ 已将外键逻辑上移至 SQL 层，但 phpMyAdmin 5.1 仍基于旧协议交互，若服务端是新版，需额外确认 binlog 格式为
ROW（否则 CDC 场景下级联可能不被完整捕获）
真正的难点不在导入动作本身，而在确认“约束被 MySQL 加载”和“级联行为被真实触发”之间那层薄薄的、不报错也不提示的间隙。很多人卡在这里三天，最后发现只是某张表漏写了 ENGINE=InnoDB。
