性能子查詢VS加入

我執行以下兩個查詢和捕捉估計子樹成本以及統計時間性能子查詢VS加入

SET STATISTICS TIME ON 

DROPCLEANBUFFERS; 
DBCC FREEPROCCACHE 

Select Id, Name, Description 
from tblProducts 
where ID IN 
(
Select ProductId from tblProductSales 
) 

DBCC DROPCLEANBUFFERS; 
DBCC FREEPROCCACHE 

Select distinct tblProducts.Id, Name, Description 
from tblProducts 
inner join tblProductSales 
on tblProducts.Id = tblProductSales.ProductId

所以，結果我得到的是

預計子樹成本（子查詢） - 0.458276 估計子樹成本（加入） - 0.458982

統計時間（子查詢）：

SQL Server分析和編譯時間： CPU時間= 16毫秒，經過時間= 163毫秒。

（7063行（S）的影響）

SQL Server的執行時間：

CPU時間= 109毫秒，經過的時間= 726毫秒。

統計時間（加入）：

SQL Server分析和編譯時間： CPU時間= 16毫秒，經過的時間= 654毫秒。

（7063行（S）的影響）

（1行（S）的影響）

SQL Server的執行時間： CPU時間= 62毫秒，經過的時間= 624毫秒。

所以，我們可以看到join CPU時間（62毫秒）小於subquery CPU時間（109毫秒），但預計子樹成本是join比subquery高。

那麼，誰表現更好的結論是？

來源

2017-03-08 abhimanyu pawar

您正在比較估算值和實際值。估計值是對基於統計數據的努力的評估，用於評估最佳計劃，而CPU時間實際上是發生了什麼事情。如果你對性能最好的查詢感興趣，你應該嘗試使用'WHERE EXISTS'。現在，三者之間可能沒有太大的區別 –

執行時間並不是很有用，因爲它們會受到很多因素的影響。使用'SET STATISTICS IO ON'來查看執行了什麼讀取。時間不是很有幫助。另外，表格上是否有索引？ 'tblProducts.Id'和'tblProductSales.ProductId'編入了索引嗎？ –

更高性能的查詢可能是'從tblProducts中選擇不同的Id，名稱，描述，其中存在（select * from tblProductSales where tblProducts.Id = tblProductSales.ProductId）''。這使用'exists'。在某些情況下，這可能會更快 –

估計時間可能會產生誤導。只有實時服務器統計信息是實時的並且已更新，因此localserver或類似服務器的信息不能反映真實的預計時間。

其他的一點是，這兩個查詢不好。這兩個查詢的真正版本是

Select tblProducts.Id, Name, Description from tblProducts inner join tblProductSales on tblProducts.Id = tblProductSales.ProductId group by tblProducts.Id, Name, Description

或類似的東西，不關心個語法。因此，在查看統計信息之前，您必須考慮「這是此查詢的最佳版本嗎？」如果你的答案是肯定的，那麼考慮統計數據，那麼你的統計結果將會更有意義。

來源

2017-03-08 12:16:07 Dogan

性能子查詢VS加入

回答

相關問題