导出查询是navicat迁移查询脚本最可靠方式，但仅导出sql文本，不备份名称、描述、历史、变量、分组等；导入需手动新建查询并填写名称，非执行sql；跨团队协作须靠注释文档明确环境、权限与替换规则。
导出查询 是 navicat 中迁移团队查询脚本最可靠的方式，云端同步 并不存在——navicat 没有官方云服务同步查询功能，所谓“同步”实际是本地文件手动搬运或第三方工具辅助，容易丢配置、乱编码、漏元数据。
导出查询功能：能备份什么、不能备份什么
Navicat 的 导出查询 功能（路径：菜单栏 → 文件 → 导出查询）只导出 SQL 文本内容，不包含以下关键信息：
-
查询名称和描述（导出后变成无名 SQL 块） - 执行历史、上次运行时间、绑定的连接别名
- 参数化变量（如
${date}这类 Navicat 内置变量会被原样导出，但目标环境不识别） - 查询分组/文件夹结构（所有查询扁平导出为单个文件）
所以如果你团队依赖“按模块分组查询”或常用变量模板，光靠 导出查询 会丢失组织逻辑。建议配合手动整理目录结构 + 注释说明。
导出时必须检查的三个编码与格式选项
导出对话框中，这三个设置直接影响其他成员能否正常打开和执行：
-
文件编码必须选UTF-8 with BOM（Windows 环境下 Excel/Notepad++ 才能正确识别中文注释；纯 UTF-8 在某些编辑器里会乱码） -
行尾符建议统一用CRLF（Windows 默认），避免 macOS/Linux 成员用文本编辑器打开时显示为单行长行 -
是否包含 SQL 头部注释勾选——它会写入类似/* Query Name: 用户活跃统计 */的块，是唯一能还原名称的方式
示例导出头部：
/* Query Name: 用户活跃统计 Description: 统计近7天登录用户数，排除测试账号 */ SELECT DATE(login_time) AS dt, COUNT(DISTINCT user_id) FROM login_log WHERE login_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) AND user_id NOT LIKE 'test%';
导入查询：不是“执行SQL”，而是“重建查询对象”
很多人误把 运行SQL文件 当成导入查询，结果只是执行了一次语句，没在 Navicat 查询列表里留下可复用的对象。正确做法是：
- 在目标 Navicat 中，右键对应连接 →
新建查询 - 粘贴导出的 SQL 内容（含头部注释）
- 手动填写
查询名称字段（从注释里复制） - 点保存 —— 此时才真正“导入”为一个可点击、可调度、可共享的查询对象
注意：导入连接（.ncx 文件）不包含查询，只含连接配置；备份整个 Navicat 配置目录 虽然能保留全部查询，但路径硬编码、Windows/macOS/Linux 路径不兼容，跨平台迁移极易失败。
团队协作的真实痛点：变量与权限怎么管
团队共用查询时，最大的隐性坑不是语法，而是运行上下文：
-
${env}、${today}这类变量在不同人电脑上可能未启用或配置不一致，导致查询报错或结果偏差 - 查询里写的表名如
prod_orders，在开发库叫dev_orders，没人改就直接炸 - 某成员用高权限账号导出的查询，别人低权限账号导入后一运行就提示
SELECT command denied
解决办法只有两个字：文档。在导出文件开头加一段注释块，明确写出：
-- 【运行前必读】
-- 1. 替换所有 ${env} 为实际环境标识（dev / test / prod）
-- 2. 确认当前连接具备对 orders、users 表的 SELECT 权限
-- 3. 时间范围默认为最近30天，如需调整请修改 WHERE 子句中的 DATE_SUB
没有自动同步，也没有魔法变量映射——谁用谁负责适配，这是 Navicat 查询迁移绕不开的现实。
