sql-server-2008 - 查询优化器运算符的选择-嵌套循环vs哈希匹配(或合并)

Question

我的存储过程之一花了太长时间执行。看一下查询执行计划，我能够找到花费很长时间的操作。这是一个嵌套循环物理运算符，具有外部表(65991行)和内部表(19223行)。在嵌套循环上，它显示估算的行= 1,268,544,993(将65991乘以19223)，如下所示:

我读了几篇关于用于连接的物理运算符的文章，对于这种情况下嵌套循环或哈希匹配是否会更好感到有些困惑。从我可以收集到的信息:

哈希匹配-当没有可用索引可用时，优化器使用哈希匹配，一个表比另一个小得多，并且表未在连接列上排序。同样，哈希匹配可能表明可以使用更有效的联接方法(嵌套循环或合并联接)。

问题:在这种情况下，哈希匹配会比嵌套循环更好吗？

谢谢

Answer 1

绝对。哈希匹配将是一个巨大的改进。与需要1,268,544,993行比较的嵌套循环相比，在较小的19,223行表上创建哈希，然后在较大的65,991行表中进行探查的操作要小得多。

服务器选择嵌套循环的唯一原因是它严重低估了涉及的行数。您的表是否有统计信息，如果有，是否会定期更新？统计信息使服务器能够选择良好的执行计划。

如果您已正确处理统计信息，但仍遇到问题，则可以强制其使用HASH联接，如下所示:

SELECT *
FROM
   TableA A -- The smaller table
   LEFT HASH JOIN TableB B -- the larger table

请注意，执行此操作的同时也会强制加入顺序。这意味着您必须正确安排所有表，以便它们的连接顺序有意义。通常，您将检查服务器已经具有的执行计划，并更改查询中表的顺序以使其匹配。如果您不熟悉该操作，则基本原理是每个“左”输入都首先出现，在图形执行计划中，左输入是下一个输入。涉及许多表的复杂联接可能必须将联接分组在括号内，或使用 RIGHT JOIN以获得最佳执行计划(交换左右输入，但在联接顺序的正确位置引入表)。

通常最好避免使用连接提示并强制连接顺序，因此请先执行其他操作!您可以查看表上的索引，进行分段，减小列的大小(例如，使用Unicode而不是Unicode的 varchar代替 nvarchar)，或者将查询分为多个部分(首先插入到临时表中，然后加入该表)。