Navicat 不支持原生多 DBA 实时协同编辑，必须依赖 Navicat On-Prem Server 与明确分工规范；本地连接配置无法共享，因环境强绑定且无自动同步；仅 On-Prem Server 可中心化托管查询、脚本等资产，并需配套权限管控与变更流程。
navicat 本身不提供原生的多 dba 协同编辑同一连接或表结构的实时锁机制，所谓“高效协作”必须依赖 navicat on-prem server + 明确分工规范，否则极易引发配置覆盖、sql 脚本版本混乱、权限误操作等事故。
为什么不能直接共享本地连接配置
很多人试图把 connections.ncx 文件发给同事，或复制粘贴连接参数——这在分布式环境中几乎必然失败。原因很实际：localhost 在 A 的机器上指向本地 MySQL，但在 B 的机器上可能根本没装服务；SSH 隧道配置 里的私钥路径、跳板机账号、端口转发规则，全都是强绑定个人环境的。一旦某人修改了自己本地的连接名或密码，别人同步不到，也不知该信谁的。
- 连接信息不是静态数据，而是运行时上下文，必须和执行环境耦合
- Navicat 本地连接只保存在单机
%APPDATA%\Navicat\（Windows）或~/Library/Application Support/Navicat/（macOS），无法自动同步 - 多人共用一个连接名但指向不同实例时，
查询历史和书签会互相污染
必须启用 Navicat On-Prem Server 才能真正共享对象
只有 Navicat On-Prem Server（非免费版组件）能把查询、代码段、聚合管道、BI 工作区等作为中心化资产托管。它不是云服务，而是你部署在内网服务器上的独立服务进程，所有团队成员通过 Navicat Premium 17 客户端连接它。
- 启动后，在 Navicat 导航窗格会出现
On-Prem Server节点，点击即可展开共享目录 - 拖拽本地
查询或代码段到该节点对应子目录（如Queries），即刻生效，无需手动导出导入 - 每个对象带完整元数据：创建者、最后修改时间、关联数据库项目（如
dvdrental mysql db），避免“这个 join 是谁写的？跑过没？”类问题 - 注意：
表结构变更本身不能被“共享”，只能共享用于执行变更的SQL 脚本，且必须配套review checklist（比如是否已备份、是否在低峰期执行）
DBA 分工必须落到具体动作和权限层级
光有共享工具不够，DBA 团队必须约定谁能在什么场景下动什么。Navicat 不会自动 enforce 权限，靠的是流程设计和 On-Prem Server 的项目隔离能力。
-
生产库连接只允许 DBA-A 和 DBA-B 同时拥有“只读+执行预审脚本”权限，其他人只能看到连接名，双击提示“无访问权限” - 所有
ALTER TABLE类变更，必须提交到On-Prem Server的Schema Changes项目，并由至少一名其他 DBA 在 Navicat 中打开该 SQL、点击Explain查执行计划、确认无全表扫描后再右键Run - 临时诊断查询（如慢日志分析）应存为带时间戳的
代码段，命名格式统一为diag_20260618_perf_issue_v1，避免覆盖 - Navicat 的
AI 助手默认调用外部模型，敏感表结构或字段名不得粘贴进提问框——这是最容易被忽略的泄露点
真正卡住协作效率的，从来不是 Navicat 功能缺不缺，而是团队有没有把“谁改什么、在哪改、改完怎么验”写成可执行的规则，并强制所有人从第一天起就走 On-Prem Server 这一条路径。任何绕过它的临时操作，三个月后都会变成故障排查时的第一块绊脚石。
