结构同步前须确认三件事：版本兼容（MySQL 5.7+/PostgreSQL 10+）、目标库已备份、连接用户具备SELECT/SHOW VIEW/LOCK TABLES权限；否则易致数据丢失或卡死。
结构比对前必须确认的三件事
navicat 的结构同步功能不是万能的，直接点“开始同步”大概率生成错漏 sql。先检查这三点：
- 两个连接必须使用
MySQL 5.7+或PostgreSQL 10+等 Navicat 明确支持的版本，MySQL 8.0与MySQL 5.6混用时，JSON字段、隐藏索引等特性会静默丢失 - 目标库（通常是旧库）需提前备份，Navicat 同步过程不校验数据一致性，只管结构；若误选反向同步方向，
DROP TABLE会直接执行 - 连接用户权限必须包含
SELECT（源库）、SELECT + SHOW VIEW + LOCK TABLES（目标库），缺LOCK TABLES会导致比对卡在“正在获取表元信息”
如何正确启动结构比对并过滤无效差异
Navicat 默认比对全部对象，但实际只需关注表结构变更。操作路径和关键设置如下：
- 右键源库 →
结构同步→ 在弹窗中左侧选源库，右侧选目标库 → 点下一步 - 在“对象选择”页，取消勾选
Stored Procedures、Functions、Events—— 这些对象的定义差异常因注释、换行、空格触发误报，且业务逻辑变更不该靠结构同步驱动 - 点击
选项按钮，勾选忽略列顺序和忽略默认值中的引号：MySQL 对DEFAULT '2023-01-01'和DEFAULT '2023-01-01'（带双引号）视为不同，但语义一致 - 若发现大量
ALTER TABLE ... MODIFY COLUMN而非CHANGE COLUMN，说明 Navicat 检测到字段类型微调（如VARCHAR(100)→VARCHAR(191)），这是合理差异；但若出现TEXT→MEDIUMTEXT却无业务需求，需人工核对源库建表语句是否被手动改过
生成 SQL 时绕过 Navicat 的默认陷阱
点击“下一步”后进入 SQL 预览页，这里最容易出问题：
- 默认生成的 SQL 包含
SET FOREIGN_KEY_CHECKS=0，但若目标库存在外键级联约束，该语句可能让后续ALTER TABLE失效；建议手动删掉这两行，改用SET FOREIGN_KEY_CHECKS=1结尾 - Navicat 对
ENUM字段新增值的处理是重建整个字段（MODIFY COLUMN），而非安全的ALTER TABLE ... CHANGE COLUMN ... ENUM(...)；若线上表数据量大，务必把这类语句替换成ALTER TABLE t1 MODIFY COLUMN status ENUM('a','b','c','d') NOT NULL形式 - 预览窗口右上角有
导出 SQL 文件按钮，但导出内容不含分号结尾，执行时报错ERROR 1064；必须打开文件，全局替换\n为;\n，或在 Navicat 执行前勾选每条语句后添加分号（该选项藏在“高级”标签页里）
执行前必须人工验证的三个 SQL 特征
自动生成的 SQL 不代表可直接上线，重点盯住这些模式：
- 所有
DROP INDEX语句必须出现在对应ADD INDEX之前，否则 Navicat 可能颠倒顺序导致ERROR 1091（索引不存在） - 涉及
ADD COLUMN且含NOT NULL和无默认值的，SQL 中必有DEFAULT NULL占位 —— MySQL 8.0+ 允许，但 5.7 会报错，需手动删掉DEFAULT NULL并补上真实默认值 - 若比对结果含
RENAME TABLE，检查是否由 Navicat 将CREATE TABLE AS SELECT误判为重命名（常见于临时表同步）；此时应关闭“自动重命名”选项，改用手工导出建表语句
结构同步不是黑盒操作，它生成的是“机器可读”的 SQL，不是“人可信任”的 SQL。真正耗时的永远是逐行确认字段长度、索引覆盖、字符集继承关系 —— 尤其当源库用 utf8mb4_0900_as_cs 而目标库是 utf8mb4_general_ci 时，Navicat 不提示排序规则降级风险。
