实际处理对链接服务器的查询在哪里？

Question

如何处理对链接服务器的查询？链接服务器在收到来自远程源的查询时是否使用其优化器？有几个场景我想知道：

场景一：

存储过程/视图完全依赖于链接服务器的结果集。链接服务器是否处理所有这些并随后通过网络将结果集流式传输回主服务器？

场景二：

存储过程/视图使用本地和链接数据。我假设链接服务器返回一个结果集，然后本地服务器针对它自己的本地数据执行该结果集。我还假设本地优化器在这里没有发挥作用，因为它在提供数据集之前不知道链接服务器上的任何内容。

Answer 1

我不认为这在经验上是确定性的。我的理解是整个表可以在调用服务器上进行处理，而不是在链接服务器上进行远程处理。如果两台服务器都是 SQL Server 2008+，您应该会看到如下场景：

SELECT x.foo FROM linked.db.dbo.x JOIN linked.db.dbo.y ON ...

在这些情况下，您将看到在远程服务器上处理连接、过滤器等。但这不应被解释为笼统的声明！对于略有不同的场景，您可能会在计划中看到略有不同的远程处理决策：

SELECT x.foo FROM localdb.dbo.x JOIN linked.db.dbo.y ON ...

这些适用于 SQL Server 2008+ -> SQL Server 2008+ 链接服务器。其他链接服务器（SQL Server 的较低版本，其他平台完全不同）的行为可能有所不同，并且可能与版本有关，甚至可能与特定的驱动程序版本有关，或与查询有关（例如，是使用的函数）。这当然可能取决于链接服务器帐户的权限 - 如果您看不到查询分布式部分的远程统计信息/基数，本地优化器将非常盲目，可能不会做出您想要的决定.

如果您想保证在远程服务器开始传输数据之前在远程服务器上进行处理，并且您实际上已经尝试使用四部分名称使其工作并且计划不尝试远程处理，则可以使用OPENQUERY而不是显式引用四部分名称。但是，从未在视图中尝试过。:-)

如果您遇到希望远程处理的情况，但事实并非如此，我很乐意查看实际计划和统计资料以帮助理解原因（或至少将其传递给某些我的联系人可以提供帮助）。

根据我自己的个人经验，通过尽我所能在本地进行尽可能多的查询，我发现了更多、更多、更可靠和可预测的性能。链接服务器很有用，但它们肯定不适合实时性能。虽然您可能认为它在某种意义上违反了 DRY，但我宁愿在镜像会话或复制期间支付一次该成本并拥有冗余数据，也不愿为每个跨服务器查询的次优远程处理决策付费。如果数据可以稍微延迟，则还有更多选项可用于移动数据以使其在本地可用（日志传送、SSIS、自定义）。