SQL Server支持database.schema.object三段式跨库访问，需显式指定schema且权限在运行时校验；MySQL不支持跨库存储过程调用，仅能通过SELECT跨库查数据；PostgreSQL需dblink扩展，但无事务一致性。
SQL Server 中用 database.schema.object 调用跨库对象
SQL Server 支持直接在存储过程中用全限定名访问其他数据库的对象，前提是执行账号有对应数据库的 SELECT 或 EXECUTE 权限。这不是“跨库调用”的特有语法，而是 SQL Server 解析对象名的标准方式。
常见错误是写成 database..table（缺 schema）或 database.dbo.table（但目标表实际在 sales schema 下），结果报错 Invalid object name 'xxx'。
- 必须写满三段式：
database_name.schema_name.object_name，例如Northwind.dbo.Customers - schema 名不能省略，哪怕目标对象在
dbo下，也要显式写出dbo - 如果 database 名含特殊字符（如短横、空格），需用方括号包裹：
[my-db].dbo.table - 权限检查发生在运行时，不是创建存储过程时——所以存储过程能成功创建，但执行时报
Permission denied
MySQL 8.0+ 不支持跨库函数/存储过程直接调用
MySQL 的存储过程作用域严格绑定在当前数据库，CALL other_db.procedure_name() 会直接报错 PROCEDURE other_db.procedure_name does not exist，哪怕该过程真实存在且你有权限。
真正可行的方式只有两种：
- 在目标库中创建同名
DEFINER存储过程，并显式授权调用者EXECUTE权限 - 改用
SELECT或INSERT ... SELECT等语句跨库查数据，例如SELECT * FROM other_db.users WHERE id = 123 - 避免在存储过程中硬编码库名；用变量拼接会导致 SQL 注入风险，且 MySQL 不允许在
CALL中使用变量作为过程名
PostgreSQL 用 dblink 扩展实现跨库查询
PostgreSQL 默认不支持跨库访问，必须启用 dblink 扩展。它本质是建立一个到另一数据库的连接，然后发 SQL 过去执行，返回结果集。
典型错误是忘记 CREATE EXTENSION dblink，或者连接字符串里漏了 dbname= 导致连到当前库，查出错数据。
- 先在当前库执行：
CREATE EXTENSION IF NOT EXISTS dblink - 连接串必须完整，例如：
'host=localhost port=5432 dbname=analytics user=app' - 查询语句要写成字符串字面量，注意单引号转义：
dblink('conn', 'SELECT id FROM users LIMIT 1') - 性能敏感场景慎用：每次调用都建新连接，比本地查询慢一个数量级
跨库操作最常被忽略的权限和事务边界
很多人以为只要语法对、连接通，就能跨库读写——但权限校验和事务隔离才是真坑。
比如 SQL Server 中，即使你在 A 库的存储过程里更新 B 库表，B 库的 UPDATE 权限仍需单独授予该账号；而 PostgreSQL 的 dblink 查询完全独立于当前事务，无法回滚对方库的操作。
- SQL Server：跨库 DML 需目标库显式授权，且
IMPERSONATE权限不能替代对象级权限 - MySQL：跨库
SELECT只校验当前用户对目标表的权限，不校验是否属于同一账号上下文 - 所有数据库：跨库写操作都不支持原子性事务——A 库提交成功，B 库失败，没有自动补偿机制
跨库这事，语法只是门槛，权限和事务才是卡住上线的最后一道墙。
