navicat本身不提供发布流水线，但可作为标准化流程执行终端，需以“机器校验+人工确认”替代人脑判断，重点强化结构同步、on-prem server管控和sql质量外挂检查。
线上发布失误不是偶然，而是流程断点的必然结果。Navicat 本身不提供发布流水线，但能成为标准化流程的执行终端——关键在于把「人脑判断」换成「机器校验+人工确认」的组合动作。
结构同步前必须做三件事
结构同步（Structure Synchronization）是线上发布最常出事的环节，错误往往发生在比对阶段就已埋下。
- 务必勾选
Compare character set和Compare collation：开发库用utf8mb4_unicode_ci，生产库若为utf8mb4_general_ci，同步时不会报错，但后续中文排序/比较行为会不一致 - 禁用
Compare storage engine（除非你明确要求引擎统一）：MySQL 开发环境用 InnoDB，生产环境某些归档表用 MyISAM，强行比对会导致误删或跳过 - 手动检查比对结果中的
DROP类操作：Navicat 默认允许生成DROP TABLE或DROP COLUMN，但生产环境应禁止——在同步向导的「Options」页中取消勾选Allow DROP operations
用 On-Prem Server 锁死连接与脚本来源
团队成员本地随意新建连接、粘贴 SQL 执行，是发布事故最高发路径。On-Prem Server 不是“锦上添花”，而是切断私有操作的物理闸门。
- 所有生产连接必须由管理员在 On-Prem Server 上创建并共享，成员端只能看到、不能编辑：右键连接 →
Properties→ 取消勾选Editable by members - 高频变更脚本（如加字段、建索引）必须固化为代码段（
Snippets），并推送到 Server：例如add-not-null-column片段内预置ALTER TABLE ... ADD COLUMN ... NOT NULL DEFAULT ''，避免有人漏写DEFAULT导致同步失败 - 成员执行任何变更前，必须从 Server 拉取最新版查询：右键项目 →
Refresh from On-Prem Server—— Navicat 不自动同步，这一步漏掉，90% 的“我刚改了你怎么没看到”问题就源于此
SQL 质量检查不能只靠美化
Navicat 的 Format SQL 功能会让 SELECT * 看起来很优雅，但它完全不管这是高危操作。语义层检查必须外挂。
- 本地开发阶段：用
sqlcheck -r 3 -f ./migrations/20260901_add_user_status.sql --dialect mysql扫描，-r 3表示只报高风险项（如全表扫描、无索引 WHERE、隐式类型转换） - CI 阶段拦截：在 GitLab CI 或 GitHub Actions 中加入步骤：
sqlcheck -r 2 -f *.sql || exit 1，-r 2拦截中高风险，防止带ORDER BY RAND()的分页语句上线 - Navicat 内不支持直接调用
sqlcheck，但可将扫描结果导出为 HTML 报告，放入共享项目文档区——让每次发布的 SQL 都附带一份“体检单”
真正容易被忽略的，是 Navicat 从不主动告诉你“这个连接配置已被他人更新”。哪怕管理员在 On-Prem Server 上改了生产库密码，你本地标签页里双击连接仍会尝试用旧凭据连——直到弹出 Access denied 才发现。所以，上线前最后一步永远是：关掉所有已打开的连接标签页，右键项目 → Refresh from On-Prem Server，再重新打开连接。
