必须分三步走：结构同步、数据校验、协作落地；跳过结构比对或绕过权限/备份检查会引发连锁故障；navicat结构同步不处理字段顺序、注释等隐性差异；数据同步需显式指定比对键，避免重复或误删；团队协作须共享sql脚本而非仅.ns x文件，并严格管控账号权限与操作记录。
不能直接“无缝”重构并同步——必须分三步走：结构同步、数据校验、协作落地。任何跳过结构比对或绕过权限/备份检查的操作，都会在团队环境里引发连锁故障。
结构同步前必须确认源目标角色和对象粒度
Navicat 的 Structure Synchronization 不是“一键覆盖”，它默认只对比表、视图、函数、存储过程等对象是否存在，但不会自动处理字段顺序、注释、分区定义、外键引用顺序等隐性差异。常见错误是把测试库当源、生产库当目标去同步，结果把开发中的草稿结构推到了线上。
- 源数据库必须是你已验证过的“权威结构”（比如本地开发库或 Git 管理的 DDL 脚本生成的库）
- 目标数据库必须提前清空无关对象，或确保你勾选了
Drop missing objects in target且已备份 - 如果目标库已有数据，务必取消勾选
Drop tables，改用Alter table模式，并手动检查每个ALTER语句是否支持在线变更（如 MySQL 5.6+ 的ALGORITHM=INPLACE）
数据同步时 Insert/Delete/Update 的行为边界要手动划清
用 Data Synchronization 同步数据，本质是按主键或唯一键做行级比对。一旦键不一致（比如源表用 id，目标表用 uid），或某张表没设主键，Navicat 就会跳过该表，或者误判为全量插入，导致重复数据。
- 必须在 Step 2 的
Key Mapping中显式指定比对字段，不能依赖“同名自动映射” -
Delete records勾选后，目标库多出的行会被无条件删掉——这在灰度环境或含归档数据的库中极其危险 - 大表同步建议关闭
Use transaction（尤其跨库或目标库负载高时），否则可能锁表超时；但关了之后失败无法回滚，得靠预检脚本兜底
团队协作中 profile 文件和权限配置最容易被忽略
Navicat 的同步配置保存为 .nsx 文件（即 profile），但它不包含连接密码、SSH 隧道参数、SSL 设置——这些全存在本地配置里。直接发 .nsx 给同事，对方十有八九连不上目标库。
- 给团队共享前，先用
Data Transfer导出一份带完整 DDL 的 SQL 脚本，再用Structure Synchronization生成变更脚本，两者合起来才是可审计的交付物 - 每个环境（dev/staging/prod）应使用独立数据库账号，且该账号只拥有
SELECT（源）、CREATE/ALTER/DROP/INSERT/UPDATE/DELETE（目标）最小权限，禁用GRANT OPTION - 所有同步操作必须记录在共享文档里，注明执行人、时间、profile 名称、影响表清单，而不是只说“我刚同步完了”
真正卡住团队的，从来不是 Navicat 功能本身，而是谁来确认结构变更的业务影响、谁批准删除语句、谁负责验证同步后索引是否重建成功——这些没法靠工具自动解决。
