navicat cloud 同步团队查询文件可行但存在权限与敏感信息泄露风险，关键在于同步内容与执行权限控制；应剥离连接依赖，仅同步纯sql逻辑，并通过角色权限和项目设置保障安全。
navicat cloud 同步团队查询文件本身是可行的，但默认行为容易导致权限失控或敏感信息泄露——关键不在“能不能同步”，而在于“同步什么”和“谁有权执行”。
直接拖拽 .sql 文件到 Navicat Cloud 项目里会出问题
Navicat 不区分“查询文件”和“连接上下文”，只要查询保存在某个连接节点下（比如右键某 MySQL 连接 → New Query），它就会把该查询和所属连接绑定。一旦你把整个连接移入 Navicat Cloud，这个查询就隐式携带了连接名、数据库名、甚至可能触发自动保存的登录凭证（如果勾选了 Save password）。
- 查询内容本身不会加密，任何人打开项目就能看到 SQL 文本
- 若查询里硬编码了测试账号、临时 token 或内网路径（如
LOAD DATA INFILE '/tmp/xxx.csv'），这些都会随项目同步 - 成员双击查询时，Navicat 默认尝试用当前连接上下文执行——哪怕他没权限，也会暴露连接目标（host/port/schema）
正确做法：剥离连接依赖，只同步纯查询逻辑
目标是让团队能复用 SQL，但不继承执行环境。操作要点如下：
- 新建一个独立项目（如
shared_queries.npz），不要从已有连接导入 - 在空白项目中右键 →
New Query，手动粘贴 SQL，不关联任何连接（顶部连接下拉框保持为(No Connection)） - 查询保存后，右键它 →
Properties→ 确认Connection字段为空 - 同步前检查项目设置：
File → Options → General关闭Auto-save connection passwords - 导出项目时用
Export Project → Structure Only（避免带运行时状态）
成员拿到查询后怎么安全执行？
同步后的查询文件没有绑定连接，成员必须手动选择本地已配置的连接来运行——这反而是安全优势：
- 每人用自己的账号、权限、SSH 隧道设置执行，避免共享高权限账号
- 查询里若含占位符（如
WHERE date > ?），Navicat 会弹出参数输入框，不暴露原始值 - 如果查询需跨库或调用存储过程，成员得自己确认目标库是否可达——没人能绕过本地网络策略
容易被忽略的细节：项目角色决定能否修改查询
Member 角色可执行、查看、编辑查询；Viewer 只能执行和查看，不能改 SQL；Manager 还能删文件、调权限。别给所有人 Manager——尤其当查询里有 DDL（如 DROP TABLE）时，一个误点可能直接跑在线库上。
另外，Navicat Cloud Portal 里的活动日志只记录“谁上传/下载了项目”，不记录“谁执行了哪条查询”，真要审计执行行为，得靠数据库自身的 query log 或代理层（如 ProxySQL）。
