必须用「工具 → 结构同步」且源库选容灾库、目标库选生产库；同步前需验证连接、表数量、字符集、排序规则、SQL_MODE一致性，禁用数据比对，排除非业务对象，逐条核对DDL中COLLATE、ENGINE等关键差异。
必须用「工具 → 结构同步」，且源库选容灾库、目标库选生产库——方向反了会生成删生产表的脚本，不是“比差异”，是直接触发事故。
结构同步前先确认连接可用性和基础元数据一致性
容灾库常因延迟或复制过滤导致部分对象缺失，Navicat 不报错但比对结果失真：
- 手动执行
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db'，两边对比表数量是否一致；不一致就别点「比对」，先查复制状态 - 检查
character_set_database和collation_database是否相同，尤其注意 MySQL 8.0+ 默认utf8mb4_0900_as_cs与旧库utf8mb4_unicode_ci混用会导致索引被误判为需重建 - 确认
SQL_MODE中都包含STRICT_TRANS_TABLES，否则DEFAULT ''和DEFAULT NULL可能被 Navicat 视为等价，漏掉关键字段变更
比对时必须关闭「Compare data」并手动排除非业务对象
应急场景下耗时就是风险，数据比对不仅慢，还会掩盖真实结构问题：
- 在结构同步向导中，**务必取消勾选「Compare data」** —— 容灾库可能有秒级延迟，数据行差异会污染结构判断，且「数据同步」功能根本不该在此流程出现
- 点击「高级」页，手动在「Exclude objects」里填入
schema_migrations、binlog_*、tmp_*、log_*等非业务表名，Navicat 默认全量比对，不剔除就会把临时表缺失当成结构缺陷 - 若容灾库启用了
replicate-ignore-table，对应表在比对结果中会显示为「目标库无」，这不是 bug，是复制配置的真实反映，需同步检查 MySQL 的SHOW SLAVE STATUS\G
生成脚本前逐条核对 DDL 差异，重点盯 COLLATE 和 ENGINE
Navicat 标黄的「修改」项里，90% 是元数据软差异，不是业务逻辑变更：
- 每条标黄差异必须点开底部的「DDL 比较」标签，左右并排看完整
CREATE TABLE语句——只看「操作类型」列等于盲操 - 重点关注
COLLATE值是否不同（如utf8mb4_0900_as_csvsutf8mb4_unicode_ci）、ENGINE是否从InnoDB变成MyISAM、COMMENT内容是否仅空格差异 - 右键无关差异项 → 「忽略此项」，Navicat 不支持批量忽略，跳过这步直接点「部署」，可能在生产库执行
ALTER TABLE ... CONVERT TO CHARACTER SET锁表数分钟 - 索引差异要查字段顺序和前缀长度：
KEY idx_a (col_b(10), col_a)和KEY idx_b (col_a, col_b(10))在 Navicat 看来是两个完全不同的索引，必须肉眼确认是否真需调整
真正危险的不是没发现差异，而是把 COLLATE 或 COMMENT 这类软差异当硬变更执行——它不会报错，但会在高峰期悄悄拖慢查询。应急响应时，宁可多花两分钟点开 DDL 比较，也不要信顶部那行「共发现 17 处修改」的汇总数字。
