這個加入提示是否危險？

一位同事要求我查看某些表格的索引，因爲他的查詢運行時間很長。一個多小時。這個加入提示是否危險？

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)

請注意不同的數據庫。這是從DatabaseB運行的

表1和表2的長度超過200萬條記錄。表3有十幾個記錄左右。

我查看了查詢計劃，優化器決定使用Table3作爲驅動表，將嵌套循環索引搜索到表1和表2中！

我的第一個假設是，統計數據受到嚴重搞砸上Tables1 & 2，但更新統計之前，我嘗試過加入正是如此聯接提示：在15秒內返回

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)

結果。

由於時間不夠，我把結果通知給了他，但我擔心這可能會導致問題在後面。

我應該重新審視統計問題並以這種方式解決問題嗎？糟糕的查詢計劃是否來自於來自單獨數據庫的連接？

任何人都可以根據您的經驗給我一些想法嗎？

來源

2008-12-31 Bob Probst

我會首先懷疑統計數據。

正如你所知道的，在99％的情況下應該避免加入提示，並且只有當你證明他們是絕對需要時才使用。

來源

2008-12-31 01:59:24

檢查統計信息，並在表格上索引。索引提示可能會導致問題。如果表中的數據發生更改，優化程序將無法選擇更有效的計劃，因爲您已經強制它始終使用散列。

來源

2008-12-31 02:21:30 JoshBerke

嵌套循環是不是最合適的？取表3中的12條記錄，與表1中的12條記錄匹配，匹配表2中的12條記錄。

否則，您的散列連接也會強制執行排序 - 這意味着您將散列100萬條記錄表1和表2，然後加入到表3中的12條記錄。

我會看看這兩個計劃的統計數據 - 我會懷疑循環連接實際上更有效，但被阻止或您的散列加入正在利用緩存的數據。

但是 - 是的 - 一般來說，加入提示是最後的手段。

來源

2008-12-31 03:17:30

涉及鏈接服務器的運行緩慢的查詢可能與排序規則有關。有關背景信息，請參見此處：http://blogs.msdn.com/psssql/archive/2008/02/14/how-it-works-linked-servers-and-collation-compatibility.aspx 散列連接提示強制排序順序，以便解釋性能增益。

下面是如何設置的選項：

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'

-Edoode

來源

2009-01-21 15:01:20 edosoft

這個加入提示是否危險？

回答

相關問題