最近，我正在尝试优化这个查询
UPDATE Analytics
SET UserID = x.UserID
FROM Analytics z
INNER JOIN UserDetail x ON x.UserGUID = z.UserGUID
估计执行计划显示 57% 执行表更新，40% 执行哈希匹配（聚合）。我做了一些窥探，发现了 JOIN 提示的主题。所以我在我的内部连接和 WA-ZHAM 中添加了一个 LOOP 提示！新的执行计划显示 38% 执行在表更新上，58% 执行在索引查找上。
因此，我准备开始对所有查询应用循环提示，直到我谨慎起来。经过一番谷歌搜索后，我意识到 JOIN 提示并没有很好地涵盖在BOL。所以...
- 有人可以告诉我为什么对我的所有查询应用循环提示是一个坏主意吗？我在某处读到 LOOP JOIN 是查询优化器的默认 JOIN 方法，但无法验证该语句的有效性？
- 什么时候使用 JOIN 提示？当事情发生时，幽灵克星却不在城里？
- LOOP、HASH 和 MERGE 提示之间有什么区别？ BOL 指出 MERGE 似乎是最慢的，但是每个提示的应用是什么？
感谢您抽出时间并帮助人们！
顺便说一句，我正在运行 SQL Server 2008。上面提到的统计数据是估计的执行计划。
有人可以告诉我为什么对我的所有查询应用循环提示是一个坏主意吗？我在某处读到 LOOP JOIN 是查询优化器的默认 JOIN 方法，但无法验证该语句的有效性？
因为这剥夺了优化器考虑其他更有效方法的机会。
什么时候使用 JOIN 提示？当事情发生时，幽灵克星却不在城里？
当数据分布（优化器做出决策的依据）严重倾斜并且统计数据无法正确表示时。
LOOP、HASH 和 MERGE 提示之间有什么区别？ BOL 指出 MERGE 似乎是最慢的，但是每个提示的应用是什么？
这些是不同的算法。
LOOP是嵌套循环：对于外表中的每条记录，在内表中搜索匹配项（使用可用索引）。当两个表中只有一小部分记录满足时最快JOIN和WHERE状况。
MERGE对两个表进行排序都会按排序顺序遍历它们，跳过不匹配的记录。最快的FULL JOINs 并且当两个记录集都已排序时（来自先前的排序操作或使用索引访问路径时）
HASH在临时存储（内存或tempdb）从其中一个表中搜索并从另一个表中搜索每条记录。如果任一表中的大部分记录与WHERE and JOIN健康）状况。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
