navicat的“运行选定的文本”不支持团队调试，因其仅限本地执行、无历史记录、不触发版本比对且不通知他人；团队调试必须依托navicat on-prem server共享代码段并统一配置。
navicat 的“运行选定的文本”功能本身不支持跨设备协同调试，它只是本地编辑器的执行快捷方式；团队调试必须依赖共享对象 + 协同合作机制，否则每人跑的都是孤立 sql 片段，根本无法对齐上下文。
为什么不能直接用“运行选定的文本”做团队调试
这个功能（快捷键 Ctrl+R / Cmd+R）只在当前打开的查询窗口中生效，它不会记录执行范围、不保存历史、不触发版本比对、也不通知他人。常见误用场景包括：
- 把一段带变量的 SQL 选中后执行，但变量值未定义 → 报错
ERROR: variable not found - 多人各自修改同一份查询文件，只运行自己选中的几行 → 实际执行逻辑碎片化，结果不可复现
- 在未启用
Navicat On-Prem Server或Navicat Cloud的情况下共享截图或粘贴 SQL 文本 → 缺少连接上下文、字符集、事务隔离级别等关键信息
真正能支撑团队调试的替代路径
必须把“运行选定的文本”这个操作，嵌入到可追溯、可共享、可复现的工作流里。核心是：先共享对象，再协同执行。
- 把调试用的 SQL 封装成
代码段（Code Snippet），并保存到Navicat On-Prem Server项目下 —— 这样所有成员看到的是同一份源，且修改会实时同步 - 在代码段中显式声明依赖参数，例如用
/* @param schema_name: public */注释标记可替换变量，避免硬编码 - 调试时，右键点击该代码段 → 选择
在新查询中打开→ 再手动选中需要运行的部分 → 按Ctrl+R—— 此时执行环境已继承共享连接的字符集、超时、事务设置等 - 关键操作后立即在
活动日志中确认：谁、何时、在哪条连接上、运行了哪段代码段的哪一部分
字符集与参数不一致导致的“看似成功实则错乱”
即使 SQL 语法完全正确，运行选定的文本 在不同配置下可能返回不同结果。这是团队调试中最隐蔽的问题之一。
- GaussDB 主备版默认用
UTF-8，但某成员本地配置为GBK→ 中文条件过滤失效（如WHERE name = '张三'查不到数据） - 连接参数中
keep-alive interval设置过长 → 调试中途连接被服务器断开，但 Navicat 不提示，只报connection reset - 多人共用一个连接配置，但有人在查询开头加了
SET search_path TO xxx;，其他人没注意 → 同一语句查到的是不同 schema 下的对象
解决办法不是禁用“运行选定的文本”，而是确保每次执行前，都从共享的、带完整元信息的 代码段 或 查询 对象出发，而不是从临时粘贴的纯文本开始。
容易被忽略的协作前提
所有这些操作的前提，是团队已统一启用 Navicat On-Prem Server 并完成角色分配（至少要有 成员 权限才能读写代码段）。如果还在用“导出 .sql 文件发微信”的方式协作，那么 运行选定的文本 只会放大不一致性，而不是解决它。
