SQL Server的執行計劃和行

例如的估計數，現在我有這樣一個查詢：SQL Server的執行計劃和行

select * from A1 left join A2 on A1.Column1 = A2.Column1 
left join A3 on A1.Column2 = A3.Column2 
left join A4 on A1.Column3 = A4.Column3 
.... 
left join A20 on A1.Column4 = A20.Column4

當我查看上面的查詢的執行計劃時，SQL Server表明它首先會留下A2加入A1 ，然後繼續留下參加與A3的結果...之後左連接20個表，行的估計數沒有改變（2,1百萬）

但是，如果我改變我的查詢：

select * from A1 left join A2 on Cast(A1.Column1 as bigint) = Cast(A2.Column1 as bigint) 
left join A3 on Cast(A1.Column2 as bigint) = Cast(A3.Column2 as bigint) 
left join A4 on Cast(A1.Column3 as bigint) = Cast(A4.Column3 as bigint) 
.... 
left join A20 on Cast(A1.Column4 as bigint) = Cast(A20.Column4 as bigint)

注：我所有的列可以被轉換爲bigint，因爲它只包含數字，但有時它具有前導零，所以我必須讓它的數據類型爲varchar。

現在，通過這個查詢，SQL服務器顯示它首先將A3連接到A1，然後是A4，A6，A7，A8，A10 ... A20，然後是A2，A17 ...關於估計的行數，加入13個表後，估計的行數沒有變化，但之後，每次它加入另一個表時，估計的行數急劇增加，從2百萬增加到2,6，然後3,8 ..加入後20它變成了83百萬。

任何人都可以解釋爲什麼是這樣呢？在我的第二個查詢中，爲什麼Sql server會像這樣隨機地連接表？什麼可以使估計的行數突然增加？

來源

2013-07-23 user2500561

不是一個答案，但在加盟整數數量級不是加入對字符串快... –

是的，我知道，這就是爲什麼我試着投我的專欄爲int的原因。它確實使聯接性能提高很多。但完成後加入，我要的結果插入到表中，因爲行的估計數目那樣急劇增加，它耗費了大量的時間整理，並插入到新表，甚至慢於不強制轉換爲int。 – user2500561

有幾件事情要檢查。首先每張桌上有多少數據可用？也許你的第一張桌子有1億張唱片，雖然前13張桌子只有20張，但接下來的7張桌子其他8000萬張唱片呢？我建議先創建幾行表並驗證您的數據是否正確。 –

是完全可能的，你投是混淆查詢優化方面的統計數據 - 與字符串排序「201」將是「2」和「3」之間 - 而對於BIGINT也不會。所以，同樣，如果你有一個從'1000'到'2'的字符串範圍 - 那麼作爲一個bigint範圍沒有多大意義。

我會認真考慮存儲數據的整數版本，以及，使該存儲可以是有意義的，而統計數據，那麼你很可能會得到更好的價值觀出了查詢優化器。

來源

2013-07-23 08:03:43

SQL Server的執行計劃和行

回答

相關問題