SQL 查詢語句總是先執行 SELECT？你們都錯了

2019 年 10 月 28 日
筆記

很多 SQL 查詢都是以 SELECT 開始的。不過，最近我跟別人解釋什麼是窗口函數，我在網上搜索」是否可以對窗口函數返回的結果進行過濾「這個問題，得出的結論是」窗口函數必須在 WHERE 和 GROUP BY 之後，所以不能」。於是我又想到了另一個問題：SQL 查詢的執行順序是怎樣的？

好像這個問題應該很好回答，畢竟自己已經寫了上萬個 SQL 查詢了，有一些還很複雜。但事實是，我仍然很難確切地說出它的順序是怎樣的。

SQL 查詢的執行順序

於是我研究了一下，發現順序大概是這樣的。SELECT 並不是最先執行的，而是在第五個。

這張圖回答了以下這些問題

這張圖與 SQL 查詢的語義有關，讓你知道一個查詢會返回什麼，並回答了以下這些問題：

可以在 GRROUP BY 之後使用 WHERE 嗎？（不行，WHERE 是在 GROUP BY 之後！）
可以對窗口函數返回的結果進行過濾嗎？（不行，窗口函數是 SELECT 語句里，而 SELECT 是在 WHERE 和 GROUP BY 之後）
可以基於 GROUP BY 里的東西進行 ORDER BY 嗎？（可以，ORDER BY 基本上是在最後執行的，所以可以基於任何東西進行 ORDER BY）
LIMIT 是在什麼時候執行？（在最後！）

但資料庫引擎並不一定嚴格按照這個順序執行 SQL 查詢，因為為了更快地執行查詢，它們會做出一些優化，這些問題會在以後的文章中解釋。

所以：

如果你想要知道一個查詢語句是否合法，或者想要知道一個查詢語句會返回什麼，可以參考這張圖；
在涉及查詢性能或者與索引有關的東西時，這張圖就不適用了。

混合因素：列別名

有很多 SQL 實現允許你使用這樣的語法：

SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)

從這個語句來看，好像 GROUP BY 是在 SELECT 之後執行的，因為它引用了 SELECT 中的一個別名。但實際上不一定要這樣，資料庫引擎可以把查詢重寫成這樣：

SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)

這樣 GROUP BY 仍然先執行。

資料庫引擎還會做一系列檢查，確保 SELECT 和 GROUP BY 中的東西是有效的，所以會在生成執行計劃之前對查詢做一次整體檢查。

資料庫可能不按照這個順序執行查詢（優化）

在實際當中，資料庫不一定會按照 JOIN、WHERE、GROUP BY 的順序來執行查詢，因為它們會進行一系列優化，把執行順序打亂，從而讓查詢執行得更快，只要不改變查詢結果。

這個查詢說明了為什麼需要以不同的順序執行查詢：

SELECT * FROM

如果只需要找出名字叫「mr darcy」的貓，那就沒必要對兩張表的所有數據執行左連接，在連接之前先進行過濾，這樣查詢會快得多，而且對於這個查詢來說，先執行過濾並不會改變查詢結果。

資料庫引擎還會做出其他很多優化，按照不同的順序執行查詢，不過我並不是這方面的專家，所以這裡就不多說了。

LINQ 的查詢以 FROM 開頭

LINQ（C#和 VB.NET 中的查詢語法）是按照 FROM…WHERE…SELECT 的順序來的。這裡有一個 LINQ 查詢例子：

var teenAgerStudent = from s in studentList

pandas 中的查詢也基本上是這樣的，不過你不一定要按照這個順序。我通常會像下面這樣寫 pandas 程式碼：

df = thing1.join(thing2)      # JOIN

這樣寫並不是因為 pandas 規定了這些規則，而是按照 JOIN/WHERE/GROUP BY/HAVING 這樣的順序來寫程式碼會更有意義些。不過我經常會先寫 WHERE 來改進性能，而且我想大多數資料庫引擎也會這麼做。

R 語言里的 dplyr 也允許開發人員使用不同的語法編寫 SQL 查詢語句，用來查詢 Postgre、MySQL 和 SQLite。