navicat 数据同步功能不能替代 sql 变更脚本管理，因其生成语句无事务、不校验依赖顺序、不保留上下文，易致生产事故；模型对比非真实元数据比对，存在缓存偏差；同步不处理跨库引用、权限及审计追踪，须人工审查sql并用专业工具替代。
Navicat 数据同步功能不能替代 SQL 变更脚本管理
生产环境做结构或数据变更时，直接点“同步”按钮容易出事——它生成的语句不带事务包裹、不校验依赖顺序、也不保留执行上下文。一旦中途失败，回滚只能靠人工判断。
常见错误现象：ERROR 1050 (42S01): Table 'xxx' already exists 或 Cannot add or update a child row: a foreign key constraint fails，都是因为 Navicat 按字典序执行 DDL，没考虑外键、视图、存储过程之间的依赖链。
- 只在测试库用同步功能验证逻辑，生产必须导出
SQL 文件手动审查后再执行 - 勾选
Compare data时务必关掉Ignore auto-increment value，否则主键冲突风险极高 - 如果源库有
GENERATED COLUMN或JSON字段，目标库 MySQL 版本低于 5.7.8 会静默跳过字段，不报错但数据丢失
模型对比（Model Comparison）输出的 DDL 不等于可执行迁移脚本
Navicat 的模型对比本质是图形化 diff 工具，它比对的是“当前连接看到的表结构快照”，不是数据库真正的元数据状态。比如 INFORMATION_SCHEMA 缓存未刷新、ALTER TABLE ... ALGORITHM=INSTANT 导致的列顺序错位，都会让对比结果漏掉关键差异。
使用场景：适合开发阶段快速发现两个设计稿之间的结构偏差；不适合用于生产库之间版本比对。
- 对比前先在两边库执行
FLUSH TABLES，避免缓存导致的字段缺失误判 -
ENUM类型值顺序变化不会触发变更提示，但实际会影响应用层序列化逻辑 - 对比结果里显示
ADD COLUMN，但真实环境可能需要ADD COLUMN AFTER xxx才符合业务字段分组习惯，这个细节它不体现
同步任务无法感知跨库引用和权限变更
Navicat 同步只处理当前连接的库内对象。如果表里有 SELECT * FROM other_db.table_a 这种跨库查询，或者触发器里调用了 sys_exec 函数，同步过程完全不检查这些依赖是否存在、权限是否足够。
性能影响：当开启 Compare data 且表行数超 10 万时，Navicat 默认用 COUNT(*) + 全字段 MD5 校验，会锁表并拖慢主库响应。
- 涉及跨库/跨实例的对象，必须人工补上
GRANT语句和CREATE DATABASE IF NOT EXISTS - 大数据量同步前，改用
mysqldump --where="id BETWEEN x AND y"分片导出，别依赖界面“全量同步”按钮 - 同步配置里的
Batch size建议设为1000而非默认10000，减少单次事务体积，降低主从延迟突增概率
Navicat 没有变更审计与回滚追踪能力
所有同步操作在 Navicat 日志里只记录“已执行”，不保存原始 SQL、不记录执行人、不关联工单号。出了问题没法快速定位谁在哪台机器上点了哪个按钮。
容易被忽略的地方：Navicat 的 History 面板只存本地操作记录，换电脑或重装就清空；而生产变更要求操作留痕可追溯。
- 真正上线前，把 Navicat 生成的 SQL 粘贴进公司审批系统，而不是直接点执行
- 用
pt-online-schema-change或gh-ost替代 Navicat 的在线 DDL，它们自带进度监控和中断恢复 - 如果必须用 Navicat 同步，请在执行前手动执行
SET sql_log_bin = 0（仅限从库），避免同步操作写入 binlog 干扰主从一致性判断
