SQL SERVER 2008 JOIN提示

Question

3

最近，我正在尝试优化这个查询

UPDATE Analytics
SET UserID = x.UserID
FROM Analytics z 
INNER JOIN UserDetail x ON x.UserGUID = z.UserGUID

估计执行计划显示表更新占57％，哈希匹配（聚合）占40％。我进行了一些调查，发现了JOIN提示的主题。所以我在我的内部连接中添加了一个LOOP提示，新的执行计划显示表更新占38％，索引搜索占58％。

所以我准备开始将LOOP提示应用于我所有的查询，直到谨慎起见。经过一些搜索，我意识到JOIN提示在BOL中没有得到很好的涵盖。因此...

感谢大家的时间和帮助！

顺便提一下，我正在使用SQL Server 2008。上述统计数据是估算的执行计划。

- super9

在深入研究之前，你的索引和统计信息是否是最新的？ - Paddy

2个回答

2

估计的执行计划显示表更新占57％，哈希匹配（聚合）占40％。我进行了一些调查，发现了关于JOIN提示的主题。因此，我在我的内部联接中添加了一个LOOP提示，结果新的执行计划显示表更新占38％，索引搜索占58％。假设表更新需要固定时间，那么这意味着您提出的计划更差了吗？

- Martin Smith

这是一个公平的假设吗？我一直以为将大部分工作放在索引查找上是正确的方式。 - super9

我认为这是一个公正的假设，但如果我错了，我很乐意纠正。Analytics.UserGUID上是否有聚集索引？如果有，将GUID更新为不同的值可能会导致相当多的IO，这可能解释了您遇到的任何性能问题。 - Martin Smith

我在Analytics.UserGUID上有一个非聚集索引。我正在更新UserID列而不是UserGUID。Analytics.UserID列上没有索引。 - super9

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Quassnoi · Accepted Answer

有人能告诉我为什么对所有查询应用LOOP提示是个坏主意吗？我在某处读到LOOP JOIN是查询优化器的默认JOIN方法，但无法验证该说法的有效性？

这样做会剥夺优化器考虑其他更有效算法的机会。

JOIN提示什么时候使用？当事情变糟且没有Ghostbusters在城里时？

当数据分布（优化器决策依据）严重不均匀且统计信息无法正确表示时。

LOOP、HASH和MERGE提示之间有什么区别？ BOL说明MERGE似乎最慢，但每个提示的应用是什么？

这些是不同的算法。

LOOP 是嵌套循环：对于外部表中的每个记录，内部表都会搜索匹配项（利用可用的索引）。当只有很少部分记录来自两个表格满足JOIN和WHERE条件时，速度最快。
MERGE 对两个表格进行排序，按排序顺序遍历它们，并跳过不匹配的记录。在FULL JOIN和两个记录集已经排序（来自之前的排序操作或使用索引访问路径时）时，速度最快。
HASH 在临时存储（内存或tempdb）中为其中一个表格构建哈希表，并为另一个表格的每个记录搜索它。当大部分记录来自任一表格匹配WHERE和JOIN条件时，速度最快。