不能直接用子查询实现跨多个数据库实例的分布式关联检索，真正起作用的是底层连接机制（如sql server链接服务器、postgresql dblink、mysql federated引擎）是否支持跨实例访问，子查询仅作为语法外壳，依赖前置配置才能生效。
不能直接用子查询实现跨多个数据库实例的分布式关联检索——子查询本身不解决跨实例问题，它只是语法结构；真正起作用的是底层连接机制是否支持跨实例访问。
子查询在跨实例场景中只是“壳”，不是“桥”
子查询（如 WHERE id IN (SELECT id FROM ...) 或 FROM t1 WHERE col = (SELECT val FROM ...)）本身对数据库实例边界完全无感知。它能否跑通，取决于子查询里引用的对象是否可访问。
- 如果子查询里写的是
remote_db.users，而当前数据库根本无法解析这个库名（比如在 PostgreSQL 里直接这么写会报cross-database references are not implemented），那整个语句直接失败 - MySQL 允许
db1.t1 JOIN db2.t2，所以WHERE id IN (SELECT id FROM db2.t2)是合法的——但仅限同一 MySQL 实例内，不是跨实例 - SQL Server 中，
WHERE id IN (SELECT id FROM OtherServer.db.dbo.t)这种写法必须依赖已配置的链接服务器，否则报Could not find server
真正能跑通的跨实例子查询，都依赖前置连接配置
所谓“一条子查询搞定跨实例”，实际是把分布式访问能力“藏”在了对象别名或扩展函数背后。你写的还是子查询，但执行时已由底层机制接管。
- SQL Server：必须先用
sp_addlinkedserver配好链接服务器，才能在子查询中写srv_link.remote_db.dbo.users——四段式名称中的srv_link才是关键 - PostgreSQL：得靠
dblink()函数把远程查询包装成本地结果集，再用于子查询，例如：WHERE id IN (SELECT id FROM dblink('host=... dbname=prod', 'SELECT id FROM users') AS t(id int)) - MySQL：FEDERATED 引擎建的本地表映射到远程实例后，子查询里就能当普通表用，但该引擎在 8.0+ 默认禁用，且一旦远程不可达就报
ERROR 1429
最容易被忽略的三个执行陷阱
即使语法通过、配置完成，跨实例子查询仍可能在运行时崩掉，原因往往和本地查询完全不同。
- 权限检查是分层的：链接服务器登录凭据、远程库的 SELECT 权限、甚至远程表上是否有行级安全策略（RLS），任一环节缺失都会在执行时报错，而不是建语句时
- 子查询可能被重写为 JOIN：优化器有时会把
IN (SELECT ...)自动转成半连接（semi-join），而某些数据库（如旧版 SQL Server）对跨实例半连接支持极差，导致计划编译失败 - 超时不是网络层的事：
OPENQUERY或dblink的默认超时往往很短（如 30 秒），子查询若涉及大表扫描或未加索引字段，还没返回结果就断连，错误信息却只显示 “Query timeout”，掩盖真实瓶颈
跨实例子查询的“简洁”全是假象，它把复杂性从 SQL 里移走了，但没消除——而是压到了链接配置、权限链、网络稳定性这些更难调试的地方。
