子查询本身不支持跨服务器访问，必须先配置链接服务器（sp_addlinkedserver）、绑定登录（sp_addlinkedsrvlogin），并严格使用四段式命名；否则会因缺失远程服务器注册或命名不全而报错。
不支持——子查询本身没有跨服务器能力，它只是语法结构，能否访问远程服务器完全取决于底层连接机制是否就绪。
子查询跨服务器失败，90%是链接服务器没配好
SQL Server 里写 WHERE id IN (SELECT id FROM [RemoteSrv].[db].[dbo].[t]) 报错 Could not find server 'RemoteSrv' in sys.servers，不是子查询写错了，而是 sp_addlinkedserver 根本没执行过。必须先注册链接服务器，再授权登录凭据：
- 用
sp_addlinkedserver注册，@server参数名要和子查询里四段式名称的第一段完全一致（大小写敏感） - 紧接着用
sp_addlinkedsrvlogin绑定账号，@useself = 'false'是常态，不能省 - 如果要用
OPENDATASOURCE或OPENROWSET做临时调用，还得提前开开关：EXEC sp_configure 'Ad Hoc Distributed Queries', 1; RECONFIGURE;
四部分命名漏一不可，方括号不是可选装饰
子查询里引用远程表，必须严格写成 [LinkedServerName].[DatabaseName].[SchemaName].[TableName]。漏掉任意一部分，SQL Server 就当成本地对象处理：
-
SELECT * FROM local_t WHERE id IN (SELECT id FROM RemoteDB.dbo.t)❌ 缺少链接服务器名，报Invalid object name 'RemoteDB.dbo.t' -
SELECT * FROM local_t WHERE id IN (SELECT id FROM [RemoteSrv].[SalesDB].[dbo].[Orders])✅ 正确，四段齐全 - 远程表名含数字开头（如
[2024_logs]）、短横（[my-db]）或大小写混用，方括号必须保留，否则解析失败
能跑通≠能高效，子查询不会自动下推条件
SQL Server 默认把整个远程表拉到本地再过滤，不是在远程库上执行 WHERE。一张百万行的表被全量传输，网络和内存立刻打满：
- 避免裸写
(SELECT id FROM [RemoteSrv].[db].[dbo].[t])，强制加TOP或WHERE限制数据量：(SELECT TOP 1000 id FROM [RemoteSrv].[db].[dbo].[t] WHERE status = 'active') - 更可靠的做法是改用
OPENQUERY，把完整 SQL 字符串发给远程执行：SELECT * FROM OPENQUERY(RemoteSrv, 'SELECT id FROM db.dbo.t WHERE status = ''active''') - 远程字段（如
status）必须有索引，否则远程端也会全表扫描
跨实例对比数据时，NOT IN 是隐形陷阱
用 WHERE id NOT IN (SELECT id FROM [RemoteSrv].[db].[dbo].[t]) 查缺失记录，只要远程子查询返回任意一个 NULL，整行就静默消失——你查不到差，只以为数据全对上了：
- 必须改用
NOT EXISTS：WHERE NOT EXISTS (SELECT 1 FROM [RemoteSrv].[db].[dbo].[t] u WHERE u.id = local_t.id) - 子查询里固定写
SELECT 1，不写SELECT *或SELECT id，避免字段传输和优化器误判 - 浮点字段比对要加容差：
ABS(local_sum - remote_sum) > 0.01；空值统一用COALESCE处理
真正决定跨服务器能力的是链接服务器、postgres_fdw 或 FEDERATED 引擎这些底层配置，不是子查询嵌套多深。写得再“嵌套”，没配好连接，照样报错；配好了，但没注意权限、下推、NULL 处理，照样查不准、跑不动。
