Navicat 17 不支持 SQL 查询脚本的云端同步，所有未保存的查询仅存于内存或本地配置中，关机或重装即丢失；可靠方案是手动保存为 .sql 文件并用 Git 管理。
Navicat 17 本身不提供 SQL 查询脚本的云端同步功能
它不会自动把你在查询编辑器里写的 SELECT、UPDATE 或未命名的标签页内容上传到任何云端服务。所谓“同步查询脚本”，在 Navicat 中根本不存在对应机制——它的“同步”功能（Tools → Data Synchronization）只处理**表中数据行的比对与搬运**，和你写的 SQL 文本完全无关。
所有未显式保存的查询内容，都只驻留在客户端内存或本地配置目录（如 Windows 的 %AppData%\PremierSoft\Navicat Premium\ 下的 SQLite 数据库），关机、崩溃、重装即丢失。哪怕勾选了“恢复上次会话”，也只恢复已打开的连接和表，不包括未命名的查询标签页。
真正能落地的“同步到云端”路径：手动保存 + 外部 Git 管理
把查询当代码管，不是当临时笔记记。这是唯一可靠、可追溯、跨设备复用的方式：
- 每次写完关键查询（比如带
JOIN或窗口函数的报表语句），立刻按Ctrl+S，存为带明确用途和日期的.sql文件，例如user_retention_weekly_20261021.sql - 把这些
.sql文件统一放在一个本地文件夹里，初始化为 Git 仓库：git init，然后git add . && git commit -m "add weekly retention query" - 推送到私有远程（GitHub Private、GitLab Self-Hosted、或企业 NAS 上的 bare repo），就完成了“同步到云端”的实质动作
- 在另一台机器上
git clone，就能拿到全部历史查询；配合 Navicat 的File → Execute Batch Job，还能一键批量运行
别被“另存为查询”误导：它只是本地缓存，不是云端同步
Navicat 提供的 右键查询标签 → 另存为查询，看似是保存操作，但实际只是把脚本存进当前连接的“查询”节点下——本质是写入 Navicat 自己的配置数据库（connections.ncx 或用户目录下的 SQLite 文件），并非独立文件。
这意味着：
- 换电脑、重装 Navicat、甚至只是迁移用户配置目录，这些“已保存的查询”都会消失
- 无法用文本工具搜索、无法做 diff、无法设置权限、无法被 CI/CD 流程识别
- 导出连接（
File → Export Connections）时，这些查询内容**完全不会被打包进去**，只导连接参数
如果非要自动化，只能靠外部脚本监听 + Git 提交
Navicat 没有 API 或钩子暴露查询编辑器内容，所以无法从内部触发自动提交。但你可以用轻量级外部方案补位：
例如在 Windows 上用 PowerShell 脚本定时扫描你指定的查询脚本目录（如 D:\navicat-queries\），检测新增或修改的 .sql 文件，自动执行：
git add . && git commit -m "auto-commit $(Get-Date -Format 'yyyy-MM-dd HH:mm')" && git push
注意：这仍依赖你**先手动保存为独立文件**。Navicat 不会生成这些文件，它只负责执行它们。
最常被忽略的一点：很多人以为“开了自动备份任务”或“用了数据同步”，查询脚本就安全了——其实两者压根不碰你的 SQL 文本。防丢这件事，必须从第一行 SELECT 开始，就决定它是临时草稿，还是正式代码。
