SQL 查詢的執行順序
SELECT語句的完整語法如下
SELECT DISTINCT <select_list> FROM <left_table> <join_type> JOIN <right_table> ON <join_condition> WHERE <where_condition> GROUP BY <group_by_list> HAVING <having_condition> ORDER BY <order_by_condition> LIMIT <limit_number>
然而其執行順序卻是:
FROM <表名> # 笛卡爾積 ON <篩選條件> # 對笛卡爾積的虛表進行篩選 JOIN <join, left join, right join...> <join表> # 指定join,用於新增資料到on之後的虛表中,例如left join會將左表的剩餘資料新增到虛表中 WHERE <where條件> # 對上述虛表進行篩選 GROUP BY <分組條件> # 分組 <SUM()等聚合函式> # 用於having子句進行判斷,在書寫上這類聚合函式是寫在having判斷裡面的 HAVING <分組篩選> # 對分組後的結果進行聚合篩選 SELECT <返回資料列表> # 返回的單列必須在group by子句中,聚合函式除外 DISTINCT # 資料除重 ORDER BY <排序條件> # 排序 LIMIT <行數限制>
其實,引擎在執行上述每一步時,都會在記憶體中形成一張虛擬表,然後對虛擬表進行後續操作,並釋放沒用的虛擬表的記憶體,以此類推。
具體解釋:(注:下面“VT”表示 → 虛擬表 virtual )
from:select * from table_1, table_2; 與 select * from table_1 join table_2; 的結果一致,都是表示求笛卡爾積;用於直接計算兩個表笛卡爾積,得到虛擬表VT1,這是所有select語句最先執行的操作,其他操作時在這個表上進行的,也就是from操作所完成的內容
on: 從VT1表中篩選符合條件的資料,形成VT2表;
join: 將該 join 型別的資料補充到VT2表中,例如 left join 會將左表的剩餘資料新增到虛表VT2中,形成VT3表;若表的數量大於2,則會重複1-3
where: 執行篩選,(不能使用聚合函式)得到VT4表;
group by: 對VT4表進行分組,得到VT5表;其後處理的語句,如select,having,所用到的列必須包含在group by條件中,沒有出現的需要用聚合函式;
having: 篩選分組後的資料,得到VT6表;
select: 返回列得到VT7表;
distinct: 用於去重得到VT8表;
order by: 用於排序得到VT9表;
limit: 返回需要的行數,得到VT10;
需要注意的是:
- group by條件中,每個列必須是有效列,不能是聚合函式;
- null值也會作為一個分組返回;
- 除了聚合函式,select子句中的列必須在group by條件中;
除了聚合函式,select子句中的列必須在group by條件中;
- 可以在 GRROUP BY 之後使用 WHERE 嗎?(不行,GROUP BY 是在 WHERE 之後!)
- 可以對視窗函式返回的結果進行過濾嗎?(不行,視窗函式是 SELECT 語句裡,而 SELECT 是在 WHERE 和 GROUP BY 之後)
- 可以基於 GROUP BY 裡的東西進行 ORDER BY 嗎?(可以,ORDER BY 基本上是在最後執行的,所以可以基於任何東西進行 ORDER BY)
- LIMIT 是在什麼時候執行?(在最後!)
但是,資料庫引擎並不一定嚴格按照這個順序執行 SQL 查詢,因為為了更快地執行查詢,它們會做出一些優化,這些問題會在下方進行解釋↓↓↓。
SQL中的別名會影響SQL執行順序麼
如下方SQL所示:
SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)
FROM table
GROUP BY full_name
從這個語句來看,好像 GROUP BY 是在 SELECT 之後執行的,因為它引用了 SELECT 中的一個別名。但實際上不一定要這樣,資料庫引擎會把查詢重寫成這樣↓↓↓:
所以,這樣 GROUP BY 仍然先執行。
另外,資料庫引擎還會做一系列檢查,確保 SELECT 和 GROUP BY 中的東西是有效的,所以會在生成執行計劃之前對查詢做一次整體檢查。
資料庫很可能不按正常順序執行查詢(優化)
在實際當中,資料庫不一定會按照 JOIN、WHERE、GROUP BY 的順序來執行查詢,因為它們會進行一系列優化,把執行順序打亂,從而讓查詢執行得更快,只要不改變查詢結果。
這個查詢說明了為什麼需要以不同的順序執行查詢:
SELECT * FROM
dept d LEFT JOIN student s ON d.student_id = s.id
WHERE s.name = '陳哈哈'
如果只需要找出名字叫“陳哈哈”的學生資訊,那就沒必要對兩張表的所有資料執行左連線,在連線之前先進行過濾,這樣查詢會快得多,而且對於這個查詢來說,先執行過濾並不會改變查詢結果。