问题标签 [join-hints]

一位同事要求我查看一些表的索引，因为他的查询运行时间很长。一个多小时。

注意不同的数据库。这是从 DatabaseB 运行的

表 1 和表 2 的记录超过 200 万条。Table3 有十几条记录。

我查看了查询计划，优化器决定对表 1 和表 2 进行嵌套循环索引搜索，表 3 作为驱动表！

我的第一个假设是 Tables1 和 2 上的统计信息严重混乱，但在更新统计信息之前，我尝试添加一个连接提示：

结果在 15 秒内返回。

由于时间紧迫，我将结果反馈给了他，但我担心这可能会导致以后出现问题。

我应该重新审视统计问题并以这种方式解决问题吗？错误的查询计划可能是因为连接来自单独的数据库吗？

任何人都可以根据您的经验给我一些想法吗？

我正在做一个任务，我应该比较 SQL Server 中的不同连接方法，即散列连接、合并连接和索引连接。

我很难让 SQL Server 执行索引连接。谁能告诉我如何强制它使用索引连接（使用连接提示或类似方法），或者只是简单地提供一个简单的查询，其中 SQL 服务器使用索引连接方法？

与常规 JOIN（其中 SQL Server 将决定最佳 JOIN 策略）相比，显式执行 HASH JOIN 有哪些优点（如果有）？例如：

在上面的简单示例代码中，我指定了 JOIN 策略，而如果我不使用“hash”关键字，SQL Server 将在后台执行 MERGE JOIN（根据“实际执行计划”）。

我有一些临时报告用户访问了一些 SQL Server 视图。有时，这些用户对特别冗长的查询使用的读锁会在系统的其他地方引起麻烦。

我正在考虑向with(nolock)视图添加一些战略提示，但想知道是否存在与视图中的提示相关的任何问题。

请忽略让用户在 SQL 金属附近运行查询的明显问题:)。

另外，我知道 nolock 提示是一个不能轻易使用的高级功能，而且我很清楚它们会引入一些有趣的东西，比如脏读。最后，如果您认为 read_committed_snapshot 在这里有意义，我必须遗憾地说它不适用于 2000。

最近，我试图优化这个查询

估计的执行计划显示 57% 的表更新和 40% 的哈希匹配（聚合）。我做了一些窥探，并遇到了 JOIN 提示的主题。所以我在我的内部连接和 WA-ZHAM 中添加了一个 LOOP 提示！新的执行计划显示 38% 的表更新和 58% 的索引搜索。

所以我正要开始对我的所有查询应用 LOOP 提示，直到我变得更加谨慎。经过一番谷歌搜索，我意识到 JOIN 提示并没有很好地涵盖在BOL中。所以...

1. 有人可以告诉我为什么将 LOOP 提示应用于我的所有查询是一个坏主意。我在某处读到 LOOP JOIN 是查询优化器的默认 JOIN 方法，但无法验证语句的有效性？
2. 何时使用 JOIN 提示？当狗屎打到粉丝和幽灵克星不在城里？
3. LOOP、HASH 和 MERGE 提示有什么区别？BOL 指出 MERGE 似乎是最慢的，但是每个提示的应用是什么？

感谢您的时间和帮助人们！

我正在运行 SQL Server 2008 顺便说一句。上面提到的统计数据是估计的执行计划。

速记

因此，当我在下面写问题时，我找到了一种自己解决问题的方法。我想我仍然会发布这个问题，因为：

1. 有人可能会觉得它很有用。
2. 我不太明白为什么它会起作用。

无论如何，固定代码（见答案）。

我最初写道：

我花了很长时间在谷歌上搜索这个并且可以找到很多相关的答案，但没有一个与我的问题完全匹配。

我针对 SQL Server (10) 数据库运行下面的代码，它的执行速度非常快。它使用的执行计划涉及哈希连接。

然后我再次运行它，但这次取消注释前两行（DECLARE 和 SET 行），并删除 y.[in date] 旁边的“+1”并取消注释“+ @COUNTER”。现在查询需要很长时间才能完成 - 执行计划而不是使用嵌套循环。请注意，我仍然只是在日期上加一，但使用的是变量而不是常量。

问题是：我可以使用 @COUNTER 使用哈希联接而不是嵌套循环进行查询吗？

（一点背景知识：我要做的是松散匹配 x.[in date] 和 y.[in date] 以便它们在彼此相隔的指定天数内匹配。查询要使用的天数是从另一个表中的字段填充的。我首先尝试使用 datediff() 和 abs() 并且小于，但我很确定这将始终使用嵌套循环。（当我尝试时它确实如此无论如何！）

我尝试做各种参数嗅探文章中提到的所有事情，但它们并没有改变。无论如何，我没有将其作为存储过程运行。我猜这与 [in date] 字段上的索引有关。)

我怎么知道在哪里显式使用哈希提示连接？有时查询优化器如何被欺骗并应用有时会影响性能的提示？

今天我了解了 SQL Server 中的一个东西，叫做INNER LOOP JOIN.

这是什么意思？（谷歌没有帮助......或者我应该说......关于它的博客文章有点......技术性并且让我大吃一惊）。

另外，有哪些常见的场景使用INNER LOOP JOINover a standard是个好主意INNER JOIN？

我有什么似乎是损坏的索引？

这是正在发生的事情。我有两个表函数，第一个是一组案例，第二个是一组感知日期。这两组具有 1（案例）到 0 或 1（知道日期）的关系。通常我会像这样查询他们；

问题在于，并非 AwareDates 中匹配的所有行似乎都已加入。如果我添加一个加入提示，他们就会这样做。说;

我从查询计划中注意到的是，添加连接提示会在连接之前添加一种 AwareDate 数据，否则该数据不存在。此外，当没有提示时，查询计划器会将连接翻转为 RIGHT OUTER JOIN，当然，在提示存在的地方保留 LEFT JOIN。

我已经完成了以下操作，没有检测到错误；

我被难住了……有什么想法吗？

这是 UDF 定义

我进一步发现，如果我删除“WITH (NOLOCK)”表提示，我会得到正确的结果。此外，如果向 AwareDates UTF 添加连接提示，甚至在 Initials 和 Resets 之间的 LEFT JOIN 关系上添加 COLLATE Latin1_General_BIN。

查询计划行数——没有连接提示（损坏）

• 案例{实际：25,891，估计：19,071.9}
• AwareDates { 实际：24,693，估计：1,463.09 }
  • 首字母{实际：24,693，估计：1,463.09}
  • 休息{实际：985，估计：33.2671}
• AwareDates 匹配连接结果集中的 8,108 个 Cases 行

查询计划行数——带有连接提示（工作）

• 案例{实际：25,891，估计：19,071.9}
• AwareDates { 实际：24,673，估计：1,837.67 }
  • 首字母{实际：24,673，估计：1,837.67}
  • 休息{实际：982，估计：42.6238}
• AwareDates 匹配连接结果集中的 24,673 个 Cases 行

我进一步缩小了问题的范围。我可以;

和

具有不同的行数。

我的 google-fu 和 so-fu 在这里让我失望了，所以我不妨问问。

我有很多查询，其中包含多个连接。

在一个查询中，我将 header/item/details 连接在一起，并为这些记录查找各种信息。

加入时，我尽量按照它们的相关性来排列。例如：我的标题有两个查找表，所以我会在加入我的项目表之前加入这些查找表。

那是对的吗？

在查找表之前加入更大的表会更好吗？或相反亦然？

我应该loop在加入小表时使用merge提示，在加入 openrowsets 时使用提示吗？

我确信答案是“视情况而定”，但一些有效加入的一般准则会非常有帮助。谢谢！