Navicat结构同步默认不对比视图、存储过程等高级对象，上线前最常漏字段新增等变更；须手动勾选“比较视图”“比较存储过程”等选项，并验证脚本执行完整性。
用 Navicat 对比两个数据库的表结构差异
上线前最常漏的是字段新增、索引添加或约束变更。navicat 自带的「结构同步」功能能快速定位这类遗漏，但默认不对比视图、存储过程和触发器——得手动勾选。
操作路径：工具 → 结构同步 → 选择源库（开发环境）和目标库（生产环境）。关键点在于：必须点击右下角 选项 按钮，在弹窗中勾选 比较视图、比较存储过程、比较函数 和 比较触发器，否则这些对象的变更会直接被忽略。
- 如果脚本里加了
COMMENT字段注释，需额外勾选比较列注释，否则注释差异不会显示 - Navicat 默认忽略大小写，但 MySQL 在 Linux 下表名区分大小写；若生产库在 Linux 服务器上，建议提前确认
lower_case_table_names配置是否一致 - 对比前先执行
FLUSH TABLES（在目标库执行），避免因缓存导致元数据未刷新而误报“无差异”
检查 SQL 脚本是否在目标库完整执行
结构同步只看当前状态，不验证脚本执行过程。比如一个含 10 条 ALTER TABLE 的脚本，中间某条失败后后续语句没跑，Navicat 对比仍可能显示“一致”——因为失败语句没生效，而你又没加事务或错误中断逻辑。
实操建议：
- 上线脚本开头加上
SET autocommit = 0;，结尾加COMMIT;，并在每条 DDL 后加SELECT 'done: ALTER TABLE t1 ADD col INT';类似标记，便于快速定位卡点 - 在目标库执行完脚本后，用 Navicat 连接生产库，打开
查询窗口，运行SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND COLUMN_NAME = 'new_col';直接验证字段是否存在 - 别依赖 Navicat 的“运行 SQL 文件”按钮自动分号切分——它对多行注释或存储过程中含分号的语句容易切错，建议用
mysql -u -p 方式执行并重定向日志，再 grep 错误
识别 Navicat 无法捕获的隐性遗漏
有些变更 Navicat 根本不进结构对比范围，比如字符集/排序规则变更、外键级联行为修改、分区策略调整，甚至 ENGINE=InnoDB ROW_FORMAT=COMPRESSED 这类建表参数。
这类问题只能靠人工核对原始脚本与目标库实际定义：
- 用
SHOW CREATE TABLE t1\G输出建表语句，复制到文本编辑器，和上线脚本里的CREATE TABLE或ALTER TABLE ... ENGINE=...行逐字比对 - 检查字符集：运行
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db';，和脚本中CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci是否一致 - 外键缺失常表现为 Navicat 显示“无外键”，但脚本里写了
ADD CONSTRAINT fk_xxx FOREIGN KEY——原因往往是脚本执行时父表字段类型不匹配（如 INT vs BIGINT），MySQL 静默跳过，不报错也不建
为什么 Navicat 的“数据同步”不能代替上线检查
上线脚本通常不含数据变更，但有人会误用 Navicat 的「数据同步」功能来“补数据”，这极其危险：它默认按主键或唯一键匹配，一旦目标库有脏数据或主键冲突，可能覆盖、删除或重复插入。
更隐蔽的问题是时间戳字段：如果表里有 created_at DATETIME DEFAULT CURRENT_TIMESTAMP，Navicat 数据同步会把源库的时间值原样写入，导致线上记录的创建时间被篡改，审计出问题。
结论很直接：上线脚本检查只盯结构、权限、参数三类；数据一致性必须由业务侧用校验逻辑兜底，不是 Navicat 的活。
真正容易被忽略的，是脚本里那些没显式声明、但依赖 MySQL 全局变量的行为——比如 sql_mode 不同会导致 INSERT INTO t VALUES () 在严格模式下直接失败，而 Navicat 对比完全不涉及这个层面。
