链接服务器两种查询方式的性能差异、硬件影响及波动原因咨询

嘿，这个问题我碰到过不少次，咱们一步步拆解清楚～

一、两种查询的核心执行逻辑差异 #

先明确这两种写法本质是完全不同的执行路径：

• 第一种：EXEC (@Temp) AT [ls1]：这是远程执行模式。你把拼接好的SQL字符串发送到链接服务器[ls1]，所有的查询逻辑（包括扫描Table_1、打包结果）都在ls1上完成，最后只把最终的结果集传回本地客户端/本地SQL Server。
• 第二种：SELECT * FROM [ls1].[Test].[dbo].[Table_1]：这是本地驱动的远程访问模式。本地SQL Server会先解析这个查询，然后向ls1发起数据请求，ls1只负责扫描表并把 raw 数据传回本地，本地再完成后续的处理（哪怕只是SELECT *，也需要本地接收、整理后再返回给客户端）。

二、服务器与客户端硬件差异的影响 #

硬件强弱确实会直接影响性能，分三种情况看：

• 链接服务器（ls1）硬件强于本地：优先选第一种。强大的远程硬件能更快完成表扫描和数据打包，减少整体执行时间；第二种的话，本地可能会成为瓶颈——比如本地网络带宽不够、CPU处理传入数据的速度跟不上，拖慢整体流程。
• 链接服务器硬件弱于本地：这种情况两种写法的瓶颈其实都在ls1的扫描速度，但第二种可能会因为本地的一些优化（比如批量接收的策略）偶尔表现稍好，但整体差异不会太大。如果数据量很大，第一种还是更优，因为不需要本地额外处理，只等结果就行。
• 两者硬件相当：差异主要在网络交互的开销。第一种是远程执行后批量返回结果，第二种是本地发起的多次数据拉取请求（底层的TDS协议交互次数更多），所以第一种通常会更稳定，但如果数据量极小，可能差异感知不明显。

三、为什么测试结果时快时慢？ #

你遇到的“有时第一种快、有时第二种快”，大概率是以下几个变量在影响：

• 缓存命中情况：不管是ls1上的数据缓存（比如表数据是否已经加载到内存）、还是两边的执行计划缓存，都会直接影响速度。比如第一次执行后ls1缓存了Table_1的数据，第二次用第一种写法就会快很多；但如果第二次用第二种写法，本地刚好缓存了访问远程表的执行计划，也可能反超。
• 网络波动：网络带宽的临时占用、延迟的波动是最常见的原因。比如某一时刻本地和ls1之间的网络拥堵，第二种写法因为需要多次交互，受影响更大；而如果刚好远程执行时网络稳定，第一种就会更快。
• 服务器临时负载：ls1或本地SQL Server如果在测试时刚好有其他任务在跑（比如备份、其他查询），就会拖慢对应写法的执行速度。比如ls1正在做磁盘IO密集型任务，第一种远程执行就会变慢；本地CPU被占满，第二种处理传入数据就会卡顿。
• 执行计划的细微差异：两种写法的执行计划（远程 vs 本地生成的远程访问计划）可能在批量获取行数、数据压缩策略上有细微不同，这些小差异在不同的测试场景下会导致性能波动。
• 统计信息过时：如果ls1或本地的表统计信息不是最新的，生成的执行计划可能不是最优的，偶尔选到高效计划就快，反之就慢。

小建议 #

如果想得到更稳定的测试结果，可以：

• 每次测试前清除两边的缓存（比如DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE，注意只在测试环境用！）
• 多次测试取平均值，排除单次波动的影响
• 查看执行计划：第一种可以用SET SHOWPLAN_XML ON配合EXEC ... AT看远程执行计划；第二种直接看本地生成的执行计划，对比两者的开销点。

内容的提问来源于stack exchange，提问作者Arash Ghasemi Rad