SQL Server查詢性能 - 普通加入VS子查詢

我有兩個查詢返回相同的數據。SQL Server查詢性能 - 普通加入VS子查詢

查詢1，這是正常的加入需要很長的時間來執行：

爲了通過bigtable.id遞減

SELECT TOP 1000 bigtable.*, tbl1.name, tb2.name FROM 
bigtable INNER JOIN tbl1 on bigtable.id1 = tbl1.id1 AND 
INNER JOIN tbl2 on tbl1.id1 = tbl2.id1

QUERY2使用子查詢返回相當迅速：

SELECT subtable.*, tbl1.name, tb2.name FROM 
(SELECT TOP 1000 FROM bigtable) subtable 
INNER JOIN tbl1 on subtable.id1 = tbl1.id1 AND 
INNER JOIN tbl2 on tbl1.id1 = tbl2.id1 
order by subtable.id desc

bigtable包含100k行左右。 tbl1是一個非常小的表（少於10行）。我寧願不使用子查詢。如果我跳過order by子句，則兩個查詢都會很快運行。我已經嘗試添加索引到正在加入的字段，添加ID等DESC索引，但似乎沒有任何幫助。

任何幫助表示讚賞！

===>更新：

這原來是一個非問題。在創建另一個類似tbl1的表具有相同的行後，我發現Query1在第二個表格下運行（使用複製的表）。重建tbl1的統計信息，並修復它。

來源

2017-02-13 Hari

我認爲，這兩個查詢是不等價的 - 嘗試寫第二個爲

SELECT subtable.*, tbl1.name, tb2.name FROM 
(SELECT TOP 1000 FROM bigtable order by bigtable.id desc) subtable 
INNER JOIN tbl1 on subtable.id1 = tbl1.id1 AND 
INNER JOIN tbl2 on tbl1.id1 = tbl2.id1 
order by subtable.id desc

我想到昂貴的操作是大表，這是目前存在兩個版本的順序。

來源

2017-02-13 23:41:21

我想先做出一家快（即我不是試圖優化子查詢）。 – Hari

但是你錯過了這兩個查詢實際上並不相同的事實：第一個在**訂購10萬條記錄後選擇前1000個記錄**，這就是它更昂貴的原因。第二個，就像你寫的那樣，從大表**中選擇前1000條記錄而不需要**，這當然是一個非常便宜的操作，然後將結果與小表結合起來，然後訂購1000條記錄。我重寫子查詢不進行優化，而是使之等同於第一個查詢。如果我是正確的，那麼你應該將你的JOIN性能與修正後的子查詢進行比較。 –

順便說一句，我在我的文章中發現了一個錯字，子查詢應該包含子句「order by bigtable.id」，而不是「order by subtable.id」。我相應地編輯了我的答案。 –

SQL Server查詢性能 - 普通加入VS子查詢

回答

相關問題