仅仅通过JOIN指定HASH JOIN的优势？

Question

如果有的话,在常规JOIN上显式执行HASH JOIN有哪些优点(其中SQL Server将决定最佳的JOIN策略)？例如:

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

在上面简单的示例代码中,我指定了JOIN策略,而如果我省略"hash"关键字,SQL Server将在幕后进行MERGE JOIN(根据"实际执行计划").

Answer 1

optmiser在日常使用中做得非常好.然而,从理论上讲,可能需要3周时间才能找到完美的计划,因此生成的计划有可能不理想.

除非你有一个非常复杂的查询或大量的数据,否则我就不管它,它根本无法产生一个好的计划.然后我会考虑它.

但随着时间的推移,随着数据的变化/增长或索引的变化等,您的JOIN提示将变得过时并阻止最佳计划.JOIN提示只能在开发时使用您拥有的那组数据优化该单个查询.

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

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

我已经看到其他开发人员使用它们,但只有在复杂视图嵌套的复杂视图的情况下,它们在重构后才会导致后续问题.

编辑:

我今天进行了一次转换,其中一些同事将使用它们强制执行错误的查询计划(使用NOLOCK和MAXDOP 1)来"鼓励"迁移远离其下游系统之一直接调用的传统复杂嵌套视图.