Sql 这有危险吗？

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

select count(1)
from databaseA.dbo.table1
inner join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

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

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

我查看了查询计划，优化器决定在表1和表2中进行嵌套循环索引查找，并将表3作为驱动表

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

select count(1)
from databaseA.dbo.table1
inner HASH join databaseA.dbo.table2 on (table1.key = table2.key)
inner join databaseB.dbo.table3 on (table1.key = table3.key)

结果在15秒内返回

由于时间不够，我把结果传给了他，但我担心这可能会导致今后的问题

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

---

有谁能根据你的经验给我一些建议吗？

我首先怀疑统计数字

---

毫无疑问，您知道，在99%的情况下应该避免使用连接提示，并且只有在您有证据证明它们是绝对必需的情况下才使用连接提示。

首先检查统计信息，并在表上建立索引。索引提示可能会导致问题。如果表中的数据发生更改，优化器将无法选择更有效的计划，因为您已强制它始终使用哈希。

嵌套循环不是最合适的吗？从表3中取出12条记录，与表1中的12条记录匹配，与表2中的12条记录匹配

否则，您的散列联接也将强制执行排序——这意味着您将对表1和表2中的100万条记录进行散列，然后联接到表3中的12条记录

我会查看这两个计划的统计数据——我怀疑循环连接实际上更有效，但被阻止了，或者您的哈希连接利用了缓存数据

---

但是-是的-一般来说，连接提示是最后的选择。

涉及链接服务器的运行缓慢的查询可能与排序有关。 请参见此处了解一些背景信息： hash join提示强制排序器，因此可以解释性能提高的原因

以下是如何设置选项：

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'collation compatible', 
    @optvalue=N'true'

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'use remote collation', 
    @optvalue=N'false'

-伊多德