sql-server - 指定 HASH JOIN 比仅执行 JOIN 有何优势？

Question

与常规 JOIN(其中 SQL Server 将决定最佳 JOIN 策略)相比，显式执行 HASH JOIN 有何优点(如果有的话)？例如:

select pd.*
from profiledata pd
inner hash join profiledatavalue val on val.profiledataid=pd.id

在上面的简单示例代码中，我指定了 JOIN 策略，而如果我省略“散列”关键字，SQL Server 将在幕后执行 MERGE JOIN(根据“实际执行计划”)。

Answer 1

优化器对于日常使用来说已经足够好了。但理论上极端情况下可能需要3周的时间才能找到完美的计划，因此生成的计划有可能并不理想。

我不会管它，除非你有一个非常复杂的查询或大量的数据，而它根本无法产生一个好的计划。那我就考虑一下。

但是随着时间的推移，随着数据的变化/增长或索引的变化等，您的 JOIN 提示将变得过时并妨碍最佳计划。 JOIN 提示只能在开发时使用您拥有的数据集针对单个查询进行优化。

就我个人而言，我从未在任何生产代码中指定过 JOIN 提示。

我通常通过更改查询、添加/更改索引或分解它(例如首先加载临时表)来解决错误的连接。或者我的查询是错误的，或者我进行了隐式数据类型转换，或者它突出显示了我的架构中的缺陷等。

我见过其他开发人员使用它们，但仅限于复杂 View 嵌套在复杂 View 上的情况，并且在重构时会导致后来的问题。

编辑:

我今天进行了一次转换，一些同事将使用它们来强制执行错误的查询计划(使用 NOLOCK 和 MAXDOP 1)，以“鼓励”迁移远离下游系统之一直接调用的遗留复杂嵌套 View 。