跨服务器查询提速关键在减少传输量、规避重复拉取、控制数据流向；应缓存静态远程表、避免循环引用、推计算逻辑至远程端，并用确定性条件替代函数过滤。

跨服务器查询在 SQL 存储过程中天然带来网络开销，不能靠“写得更短”来提速，关键在于减少传输量、规避重复拉取、控制数据流向。

用四段式引用前先确认远程对象是否真需实时访问

SQL Server 中的 [ServerName].[DatabaseName].[SchemaName].[TableName] 看似方便，但每次执行都触发一次远程 RPC 调用。如果远程表只是配置类小表（如 CountryCodes），应考虑在本地缓存副本并定时同步，而非每次都跨网查询。

• 检查远程表数据变更频率：静态表建议每日凌晨用 INSERT INTO ... SELECT 同步一次
• 避免在循环或游标中反复引用远程表——哪怕只查一行，每次都是独立网络往返
• 若必须实时读取，优先用 SELECT TOP 1 + 明确 WHERE 条件，禁用 SELECT *

把计算逻辑尽量推到远程服务器端执行

不要在本地存储过程中拉回整张远程表再 JOIN 或过滤。SQL Server 的链接服务器默认会把本地条件下推，但复杂表达式（如函数包裹字段、子查询）常导致全表拉取。

• 错误写法：WHERE YEAR(RemoteDate) = 2025 → 远程表所有 RemoteDate 全部传回本地计算
• 正确写法：WHERE RemoteDate >= '2025-01-01' AND RemoteDate → 下推生效，远程端直接过滤
• 更稳妥方式：在远程服务器上建视图或存储过程封装好过滤逻辑，本地只调用 EXEC [RemoteServer]...sp_GetFilteredData

禁用分布式事务，改用两阶段数据搬运

只要存储过程中同时操作本地内存优化表和远程表，SQL Server 就会强制启用分布式事务（DTC），这不仅慢，还可能因网络抖动失败。

• 明确禁止在单个 BEGIN TRAN 内混用本地内存优化表与远程四段式引用
• 改用分步搬运：先用 SELECT ... INTO #temp FROM [Remote]... 拉数据进临时表（非内存优化），再用第二段事务处理本地业务逻辑
• 注意临时表生命周期——#temp 在存储过程退出后自动销毁，别误用 ##global 引发并发冲突

监控实际网络流量，而不是只看执行时间

执行计划里看不到网络耗时，STATISTICS IO 和 STATISTICS TIME 也只统计本地部分。真正瓶颈常藏在远程端的物理读和网络包大小里。

• 在远程服务器上开启 SET STATISTICS IO ON，单独执行等效查询，观察 logical reads 是否异常高
• 用 Windows 性能监视器抓取 SQLServer:Network Interface\Bytes Sent/sec，对比跨库前后数值
• 若发现单次查询发送 MB 级数据，说明没做好字段裁剪或条件下推，不是网络带宽问题，是逻辑问题

跨服务器查询的性能损耗，80% 出现在“以为自己在本地操作”的错觉里——只要出现四段式引用，就要默认它是一次独立的、带延迟和失败风险的网络请求，所有设计必须围绕这个事实展开。