跨库嵌套查询能跑通的前提是数据库在同一实例、语法正确且权限齐全；MySQL用db_name.table_name直接引用，SQL Server必须写满三段式全限定名，PostgreSQL则必须依赖dblink扩展。
跨库嵌套查询能跑通，前提是数据库在同一实例、语法写对、权限配齐——三者缺一不可；否则不是报错就是静默漏数据。
MySQL 用 db_name.table_name 直接引用，但别漏权限
同一 MySQL 实例下，子查询里直接写 db2.logs 就行，不用额外配置。但容易卡在权限上：
- 当前用户必须对
db1.users和db2.logs都有SELECT权限，少一个就报Table 'db2.logs' doesn't exist（实际是权限拒绝，但错误信息误导） - 字段名冲突时必须加别名，比如两个库都有
id，SELECT u.id, l.id会报错，得写成u.id AS user_id, l.id AS log_id -
IN子查询里不能带LIMIT（MySQL 5.7 及更早版本直接报错），改用JOIN或先建临时表：CREATE TEMPORARY TABLE tmp_ids AS SELECT DISTINCT user_id FROM db2.logs ORDER BY created_at DESC LIMIT 10
SQL Server 必须写满三段：db_name.schema_name.table_name
漏掉任意一段都会报 Invalid object name，哪怕表真在 dbo 下也不许省略：
- 正确写法：
SELECT * FROM db1.dbo.users WHERE id IN (SELECT user_id FROM db2.dbo.logs) - 错误写法：
db2..logs（双点省略 schema）、db2.logs（没写 schema）、[my-db].users（漏了 schema） - 数据库名含短横或空格时，必须用方括号：
[my-db].dbo.users、[Sales DB].dbo.Orders - 子查询运行时才校验权限，语句能保存不代表能执行——查不到数据时先
SELECT state_desc FROM sys.databases WHERE name = 'db2'确认库状态是否为ONLINE
PostgreSQL 不能直连跨库，dblink 是刚需
PostgreSQL 实例内数据库强隔离，db2.public.logs 这种写法语法错误，必须用 dblink 扩展：
- 先启用：
CREATE EXTENSION IF NOT EXISTS dblink -
dblink()返回的是未类型化结果集，必须用AS (id INT, created_at TIMESTAMPTZ)显式声明结构，否则报column definition list is required - 连接串里
dbname=不能漏，否则默认连到当前库，查出错数据 -
NOT IN在跨库场景极危险：只要子查询返回任意NULL，整行就被过滤掉，改用NOT EXISTS更可靠
跨实例？先配外部对象，再谈嵌套查询
不同服务器上的数据库，没法靠“改写法”绕过去——必须提前配置底层桥接机制：
- MySQL：启用
FEDERATED引擎后，用CONNECTION='mysql://user:pass@host:port/dbname/table'建映射表，但远程宕机时本地查询直接报错（ERROR 1429），不适用于高可用场景 - SQL Server：必须先
sp_addlinkedserver注册链接服务器，再用四段式RemoteSrv.db2.dbo.logs，且远程库名、schema、表名大小写必须完全一致，否则静默返回空 - PostgreSQL：装
postgres_fdw后走IMPORT FOREIGN SCHEMA，比dblink更适合频繁 JOIN，但配置步骤多、事务一致性无保障
最常被忽略的不是语法，而是所有权链和执行时机：权限检查发生在运行时而非解析时，而子查询是否被下推到远端执行，得看 EXPLAIN 输出里有没有 Remote Subplan 或类似标记——没下推，意味着所有数据都拉到本地再过滤，网络和内存压力陡增。
