navicat结构同步不自动部署，但能生成可复用的版本化sql脚本；需手动比对、校验后复制sql，再经人工审核（过滤drop/rename、检查not null变更等）并包裹事务，方可用于生产环境。
结构同步不是自动部署，但能生成可复用的版本化SQL
Navicat 的 结构同步 本身不提供“自动化迭代”能力——它不集成CI/CD、不读取Git分支、也不触发远程执行。但它能稳定输出差异驱动的、带上下文注释的DDL脚本，这正是数据库版本自动化的关键原材料。
核心逻辑是：把每次开发库的结构变更，通过 结构同步 导出为一份明确的 001_add_user_status_column.sql 这类命名脚本，再交由 Flyway/Liquibase 或自研部署工具按序执行。Navicat 不替代版本管理，而是解决“怎么精准提取这一次改了什么”这个最易出错的环节。
- 必须手动执行比对并复制SQL，不能靠定时任务自动触发
- 导出的SQL默认不含事务包装，生产环境执行前需手动包裹
BEGIN; ... COMMIT;或添加SET autocommit = 0; - 脚本中不包含条件判断（如
IF NOT EXISTS），新增表/字段时若目标库已存在会直接报错
同步前必须校验字符集、排序规则与存储引擎
开发库用 utf8mb4_unicode_ci，生产库是 utf8mb4_general_ci？一个字段类型看似相同，但排序规则不一致会导致 结构同步 报告“属性不同”，甚至生成 ALTER TABLE ... CONVERT TO 这类高危语句。同样，InnoDB 和 MyISAM 混用也会被识别为差异。
这类差异在预览阶段常被忽略，但执行后可能引发主从同步中断或查询结果异常。Navicat 默认启用字符集比较，但存储引擎比较默认关闭——务必手动勾选，尤其在跨环境同步时。
- 在结构同步向导的
Options页面，确认Compare character set和Compare storage engine均已勾选 - 若开发/生产环境必须使用不同引擎（如开发用
Memory表做测试），应在比对前先排除该表，避免生成无意义或不可执行的ENGINE=修改语句 - 发现黄色警告（如
VARCHAR(255) → VARCHAR(100)）时，不要直接跳过；先查业务是否真有超长数据，否则执行后会静默截断
生产环境同步必须禁用 DROP 和 TRUNCATE 操作
Navicat 在比对时若发现目标库多出一张表、或某个字段在源库已删除，它默认会生成 DROP TABLE 或 ALTER TABLE ... DROP COLUMN。这类语句在生产环境等同于“删库跑路预备动作”，绝不能直接执行。
正确做法是在比对完成后，人工过滤掉所有 DROP、TRUNCATE、RENAME 类语句，并把涉及字段删除的操作转为“新增兼容字段 + 应用层灰度下线 + 后续清理”的三步流程。
- 右键点击比对结果列表，选择
全部校验后，再右键已校验项，选复制SQL到剪贴板——此时SQL才完整可用 - 粘贴后立即搜索
DROP、TRUNCATE、RENAME，逐条删除或注释 - 对
ALTER TABLE ... MODIFY COLUMN类语句，检查是否含NOT NULL变更；若目标表已有空值，该语句会失败，需先UPDATE补值再执行
保存同步配置文件（Profile）才能复现相同比对逻辑
两次对同一组库执行 结构同步，结果却不一样？大概率是某次漏选了 Compare comments 或误开了 Compare data。Navicat 的比对行为高度依赖向导每一步的勾选项，而这些设置不会自动记忆。
唯一的可靠复现方式，是点击向导底部的 Save Profile，把当前全部参数（连接、数据库、比对选项）存为一个 .nsync 文件。下次加载该 Profile，就能 100% 复现上次的比对范围和逻辑。
- Profile 文件本质是 XML，可纳入 Git 管理，作为“本次版本迭代所依据的结构比对基准”存档
- 不要依赖 Navicat 的“最近连接”或“历史操作”，它们不保存比对策略细节
- 团队协作时，应统一共享 Profile 文件而非口头描述“按默认设置比对”
复制SQL到剪贴板 后那一步——没人愿意花两分钟逐行检查生成的 DDL 是否真安全。但恰恰是这一步，决定了结构同步是从“提效工具”变成“事故源头”。
