必须手动调整表顺序以避免ERROR 1215：Navicat结构同步不自动解析全库外键依赖树，仅按字母序或选中顺序建表，若先建子表orders（含REFERENCES users）而users未建，则立即报错；应在「对象选择」面板将users等被引用表拖至orders上方，并关闭「Resolve dependencies automatically」确保顺序可控。
结构同步时外键依赖顺序错乱直接报 ERROR 1215
Navicat 不解析全库外键依赖树，只按表名字母序或手动选中顺序建表。一旦先执行 CREATE TABLE orders（含 FOREIGN KEY (user_id) REFERENCES users(id)），而 users 表还没建，MySQL 就会立刻抛出 ERROR 1215 (HY000): cannot add foreign key constraint。这不是连接问题，是 DDL 执行顺序硬伤。
实操建议：
- 进 Navicat「对象选择」面板，把被引用表（如
users、categories）拖到所有引用它的表（如orders、products）上方——强制重排建表顺序 - 禁用自动依赖解析：在「高级」→「DDL Options」里，取消勾选
Resolve dependencies automatically，避免旧版本或跨库场景下它瞎猜 - 导出脚本后手动验证：生成 SQL 后打开文件，确认
CREATE TABLE users出现在CREATE TABLE orders之前，且中间没夹杂其他带外键的表
MySQL 目标库上 SET FOREIGN_KEY_CHECKS = 0 没生效的常见原因
勾选了「Disable foreign key checks」却仍报错，大概率是这句被覆盖或压根没跑进去。Navicat 只在脚本开头加 SET FOREIGN_KEY_CHECKS = 0;，但源库导出的 SQL 文件自带 SET FOREIGN_KEY_CHECKS = 1;，或者你连的是 MySQL 5.6 以下版本，该变量在某些上下文不可动态修改。
验证与补救：
- 同步失败后立刻执行
SELECT @@FOREIGN_KEY_CHECKS;，结果必须是0才算真正关掉 - 若为
1，说明脚本中途被重置——检查导出的 SQL 是否含多处SET FOREIGN_KEY_CHECKS，删掉所有= 1的行 - 目标库若为 MySQL 5.5 或更早，别依赖这个开关，改用纯人工顺序建表 + 手动
ALTER TABLE ... ADD CONSTRAINT
跨异构库（如 SQL Server → MySQL）迁移时外键根本不能靠 Navicat 自动处理
Navicat 的「结构同步」仅支持同构库（MySQL→MySQL、PostgreSQL→PostgreSQL）。跨库时，它不会转换外键语法差异，比如 SQL Server 的 ON DELETE NO ACTION 在 MySQL 里不识别，Oracle 的 DEFERRABLE INITIALLY DEFERRED 更是直接报错。
必须人工干预：
- 先在源库查依赖链：
SELECT TABLE_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME IS NOT NULL; - 按父表→子表→孙表顺序整理建表列表，粘贴进 Navicat「运行 SQL 文件」手动执行
- MySQL 目标端需补约束：对源库带
ON UPDATE CASCADE的外键，MySQL 脚本里必须显式写出完整定义，不能省略ON UPDATE CASCADE
为什么“表被锁定”提示常和外键依赖问题混淆？
当你看到「Waiting for table metadata lock」卡在 CREATE TABLE orders，往往不是锁本身，而是 Navicat 正在等前面某张表（比如 users）的建表事务提交。而那个事务可能卡在更早的锁上，形成依赖链式阻塞。
别急着 KILL：
- 先运行
SHOW PROCESSLIST;，筛出状态为Waiting for table metadata lock且Time> 60 的线程 - 对每个可疑 ID，查
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = ?; - 若发现 TRX_STATE 是
lock wait，往上追它的阻塞者——TRX_QUERY 显示的语句才是真源头，不是 Navicat 当前那条
跨平台结构同步最易被忽略的点：它不校验字段类型是否真能承载外键值。比如源库 user_id INT 引用 users.id BIGINT，目标 MySQL 若把 user_id 映射成 INT，后续插入超范围值时外键虽建成功，但数据同步阶段直接崩在 Cannot add or update a child row。这得靠「字段映射」页逐列核对，不能信自动匹配。
