Navicat 16 不支持跨仓库 SQL 模块协同调用，因其仅为客户端工具，不托管、不解析、不执行任何数据库模块（如存储过程、函数），所有跨库操作须显式指定库名并依赖数据库原生权限与语法。
Navicat 16 不支持跨仓库的 SQL 模块协同调用。 它没有「SQL 模块」概念，也不提供类似 stored procedure 跨库自动解析、引用或远程执行的机制。所谓“跨仓库调用”，在 Navicat 中实际是用户对数据库原生能力的误读或功能期待错位。
Navicat 里根本没有“SQL 模块”这个实体
Navicat 是客户端工具，不托管、不编译、不运行任何 SQL 模块（如 MySQL 的 STORED PROCEDURE、PostgreSQL 的 FUNCTION、SQL Server 的 VIEW/STORED PROCEDURE）。它只做三件事：连接数据库、发送 SQL、展示结果。所有模块定义和调用逻辑，完全由目标数据库引擎负责。
常见误解来源：
- 把「保存在 Navicat 「查询」里的 SQL 脚本」当成可复用模块 → 实际只是文本，无作用域、无参数绑定、无跨库自动解析
- 看到「代码段」功能就以为能像编程语言那样 import → 它只是带标签的文本片段，粘贴后仍需手动改库名、改表名
- 用「虚拟组」归类多个连接+查询，误以为能自动路由到对应库 → 分组纯属 UI 层面组织，不改变 SQL 执行上下文
想让 SQL 在多个库间“复用”，必须靠显式指定库名
真正起作用的是数据库自身的语法支持。Navicat 不会帮你补全或重写跨库引用，你得自己写清楚：
- MySQL/PostgreSQL 支持
database_name.table_name或schema_name.table_name显式限定，但前提是当前连接用户对该库有权限 - SQL Server 支持
[server].[database].[schema].[object]四段式写法，但需启用链接服务器（sp_addlinkedserver），且 Navicat 不参与配置 - 跨库 JOIN 或 INSERT INTO SELECT 必须手写全路径，Navicat 不会自动推导或提示缺失库
示例（MySQL）：INSERT INTO prod_db.users SELECT * FROM dev_db.users WHERE created_at > '2026-09-01';
这条语句能否执行，取决于你当前连接的是 prod_db 还是 dev_db，以及用户是否同时拥有两个库的 SELECT 和 INSERT 权限 —— Navicat 不检查，也不报错，只转发给服务端，失败时返回原生错误如 ERROR 1142 (42000): INSERT command denied to user。
协作场景下，“复用 SQL”的唯一可靠方式是标准化脚本 + 权限对齐
如果你希望团队成员在不同环境（dev/test/prod）安全复用同一段逻辑，不能依赖 Navicat 功能，而要靠流程约束：
- 所有跨库 SQL 必须写成参数化模板，用
/* DB_NAME */.table占位，并在脚本开头加注释说明替换规则 - 把这类脚本统一存入 Git，配合 README.md 写清适用场景、预期权限、回滚方式
- 确保所有成员连接各环境时，使用的账号都具备对应库的最小必要权限（比如只给
SELECT和INSERT，不给DROP） - 禁用 Navicat 的「保存密码」选项，避免因密码硬编码导致脚本被误执行在错误环境
Navicat 协作功能最多同步你保存在「查询」里的这段 SQL 文本，但它不会校验、不会预检、不会隔离执行环境 —— 这些全是人工责任。
最容易被忽略的一点：Navicat 执行 SQL 时，永远以「当前激活连接」为默认上下文。哪怕你在「查询」里写了 prod_db.orders，只要双击打开的是 dev 连接，它就真去 dev 库里找 prod_db 这个数据库 —— 找不到就报错，不会自动切换连接。这个行为不是 bug，是设计使然。
