代码之家 › 专栏 › 技术社区 › Garrett

指定散列联接比仅执行联接更具优势?

join-hints sql-server-2005 join tsql sql-server

12

Garrett · 技术社区 · 17 年前

显式执行哈希联接比常规联接(SQL Server将决定最佳联接策略)有哪些优点(如果有的话)?如:

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

5 回复 | 直到 9 年前

1

14

gbn 17 年前

但随着时间的推移,随着数据的更改/增长或索引的更改等,您的连接提示将变得过时,并阻止优化计划。连接提示只能在使用您拥有的数据集进行开发时针对单个查询进行优化。

我通常通过改变查询、添加/更改索引或将其分解(例如先加载临时表)来解决错误的连接。或者我的查询是错误的,或者我有一个隐式的数据类型转换,或者它突出了我的模式中的一个缺陷等等。

我见过其他开发人员使用它们,但只在它们将复杂视图嵌套在复杂视图上的情况下使用,并且它们在以后重构时会导致问题。

编辑:

2

3

crokusek 9 年前

在检查至少一个
尝试重新安排查询后。比如转换连接到“in”或“exists”,更改连接顺序(这实际上只是一个提示),将逻辑从where子句移动到join条件,等等。

关于哈希联接何时有效的一些基本规则是联接条件不作为表索引存在以及表大小不同。如果您正在寻找技术描述,那么有一些关于散列联接如何工作的好描述。

为什么要使用任何连接提示(具有强制顺序副作用的哈希/合并/循环)?

避免执行极端缓慢的角案例(.5->10.0s)。

提供的提示在某些情况下可能并不理想,但提供了更一致的可预测运行时。使用提示时,应预先测试预期的最坏情况和最佳情况。可预测的运行时对于web服务至关重要,例如,在web服务中,严格优化的标称[.3s、.6s]查询优于范围为[.25、10.0s]的查询。新更新的统计数据和遵循的最佳实践可能会导致运行时出现较大差异。

post ...

CHECKPOINT -- flushes dirty pages to disk
DBCC DROPCLEANBUFFERS -- clears data cache
DBCC FREEPROCCACHE -- clears execution plan cache

最后一个选项可能与选项(重新编译)提示相同。

3

2

Srikar Doddi 17 年前

4

1

Joshua 17 年前

我知道,重载列是不好的。有时候,你必须接受它。

5

0

akappa 17 年前

逻辑计划优化工具不能向您保证它能找到最佳解决方案:精确的算法太慢,无法在生产服务器中使用;取而代之的是一些贪婪算法。

因此,这些命令背后的基本原理是让用户指定最佳连接策略,以防optimizator无法确定什么才是最适合采用的。