使用UNION和UNION ALL在同一查詢

我遇到了一些性能問題，我有一個查詢如下：使用UNION和UNION ALL在同一查詢

SELECT * FROM Foo 

UNION 

SELECT * FROM Boo 

UNION 

SELECT * FROM Koo

我知道肯定Koo沒有返回任何重複。我正考慮在最後使用UNION ALL，因此保存Koo的排序和截然不同的選擇時間。查詢應該是這樣的：

SELECT * FROM Foo 

UNION 

SELECT * FROM Boo 

UNION ALL 

SELECT * FROM Koo

是否會有助於或會受到一定影響BU第一UNION？

來源

2012-12-11 Moslem Ben Dhaou

測試兩種方法 - 查看查詢計劃並查看是否存在_any_差異。 – Oded

@Oded是的，但前提是您的測試數據和服務器配置具有代表性。否則，您可能會根據與您的測試設置相關的（非）優化做出錯誤的假設。即檢查您的10條記錄上的查詢計劃，如果您打算擁有10,000,000條記錄，32個內核和大量RAM，則單核，低RAM設置沒有多大用處。 – Jodrell

請注意，不僅Koo應該沒有重複項，而且Koo也不應包含任何在Foo或Boo中的行。 –

如果您知道不會有重複，請始終使用UNION ALL。

這裏有點灰色，但仍然值得 - 雖然實際上邊際。

如果它是直的UNION-UNION，SQL Server可以優化它以整理所有3個結果集並在兩者之間執行單一排序。由於排序主要是O（n log n），因此它和[（A distinct B）add C]之間的差別非常小。

更新

雖然可以執行單一合併排序，SQL服務器似乎並沒有做到這一點（至少不總是） - 所以用智慧UNION ALL絕對是值得的這裏。比較這裏的計劃：SQLFiddle（點擊「查看執行計劃」鏈接）

來源

2012-12-11 10:53:29 RichardTheKiwi

如果'Koo'是一張大桌子，我會說使用'UNION ALL'連接'Koo'有很多不同之處...所以我不確定它是否真的很微不足道 –

如果你知道somthing有用的數據，這是有道理的告訴查詢引擎。它可能會幫助制定查詢計劃。 – Jodrell

@Lukas如果SQL Server將兩種排序優化爲單個操作，那麼它會變成concat-concat-sort與concat-sort-concat，其中排序的O（n log n）性質使得差異不那麼明顯。由於SQL Server並不總是對它進行優化，所以它肯定比concat-sort-concat-sort快得多。 – RichardTheKiwi

使用UNION和UNION ALL在同一查詢

回答

相關問題