靈魂拷問,SQL 查詢語句先執(zhí)行 SELECT嗎?
大家好,我是狼王,一個愛打球的程序員
大家平時和SQL語句打交道的時間肯定不少,有寫過簡單SQL的,也有為很復雜的業(yè)務邏輯的SQL絞盡腦汁的,那我在這里問下大家一個簡單的問題:那你知道SQl語句的查詢順序是怎么樣的嗎?
當我剛看到這個問題的時候,我的內(nèi)心是這樣的
這個問題應該很好回答,畢竟自己已經(jīng)寫了無數(shù)個 SQL 查詢語句了,有一些還很復雜的。還裝不了這個逼了??
但事實是,我仍然很難確切地說出它的順序是怎樣的。
好了,不調(diào)侃了,我們先來看下SELECT語句的完整語法:
- 1. SELECT
- 2. DISTINCT <select_list>
- 3. FROM <left_table>
- 4. <join_type> JOIN <right_table>
- 5. ON <join_condition>
- 6. WHERE <where_condition>
- 7. GROUP BY <group_by_list>
- 8. HAVING <having_condition>
- 9. ORDER BY <order_by_condition>
- 10.LIMIT <limit_number>
然而其執(zhí)行順序卻是下面這樣的
- FROM
- <表名> # 笛卡爾積
- ON
- <篩選條件> # 對笛卡爾積的虛表進行篩選
- JOIN <join, left join, right join...>
- <join表> # 指定join,用于添加數(shù)據(jù)到on之后的虛表中,例如left join會將左表的剩余數(shù)據(jù)添加到虛表中
- WHERE
- <where條件> # 對上述虛表進行篩選
- GROUP BY
- <分組條件> # 分組
- <SUM()等聚合函數(shù)> # 用于having子句進行判斷,在書寫上這類聚合函數(shù)是寫在having判斷里面的
- HAVING
- <分組篩選> # 對分組后的結果進行聚合篩選
- SELECT
- <返回數(shù)據(jù)列表> # 返回的單列必須在group by子句中,聚合函數(shù)除外
- DISTINCT
- # 數(shù)據(jù)除重
- ORDER BY
- <排序條件> # 排序
- LIMIT
- <行數(shù)限制>
其實,sql引擎在執(zhí)行上述每一步時,都會在內(nèi)存中形成一張?zhí)摂M表,然后對虛擬表進行后續(xù)操作,并釋放沒用的虛擬表的內(nèi)存,以此類推。
具體過程如下:(下面“VT”表示 → 虛擬表 virtual )
- from:select * from table_1, table_2; 與 select * from table_1 join table_2; 的結果一致,都是表示求笛卡爾積;用于直接計算兩個表笛卡爾積,得到虛擬表VT1,這是所有select語句最先執(zhí)行的操作,其他操作是在這個表上進行的,也就是from操作所完成的內(nèi)容
- on: 從VT1表中篩選符合條件的數(shù)據(jù),形成VT2表;
- join: 將該 join 類型的數(shù)據(jù)補充到VT2表中,例如 left join 會將左表的剩余數(shù)據(jù)添加到虛表VT2中,形成VT3表;若表的數(shù)量大于2,則會重復1-3步;
- where: 執(zhí)行篩選,(不能使用聚合函數(shù))得到VT4表;
- group by: 對VT4表進行分組,得到VT5表;其后處理的語句,如select,having,所用到的列必須包含在group by條件中,沒有出現(xiàn)的需要用聚合函數(shù);
- having: 篩選分組后的數(shù)據(jù),得到VT6表;
- select: 返回列得到VT7表;
- distinct: 用于去重得到VT8表;
- order by: 用于排序得到VT9表;
- limit: 返回需要的行數(shù),得到VT10;
需要注意的是:
group by條件中,每個列必須是有效列,不能是聚合函數(shù);
null值也會作為一個分組返回;
除了聚合函數(shù),select子句中的列必須在group by條件中;
上述內(nèi)容讓我們知道一個查詢會返回什么,同時,也回答了以下這些問題:
- 可以在 GRROUP BY 之后使用 WHERE 嗎?(不行,GROUP BY 是在 WHERE 之后!)
- 可以對窗口函數(shù)返回的結果進行過濾嗎?(不行,窗口函數(shù)是 SELECT 語句里,而 SELECT 是在 WHERE 和 GROUP BY 之后)
- 可以基于 GROUP BY 里的東西進行 ORDER BY 嗎?(可以,ORDER BY 基本上是在最后執(zhí)行的,所以可以基于任何東西進行 ORDER BY)
- LIMIT 是在什么時候執(zhí)行?(在最后!)
但是,數(shù)據(jù)庫引擎并不一定嚴格按照這個順序執(zhí)行 SQL 查詢,因為為了更快地執(zhí)行查詢,它們會做出一些優(yōu)化,這些問題會在下方進行解釋↓↓↓。
SQL中的別名會影響SQL執(zhí)行順序么?
如下方SQL所示:
- SELECT
- CONCAT(first_name, ' ', last_name) AS full_name,
- count(*)
- FROM table
- GROUP BY full_name
從這個語句來看,好像 GROUP BY 是在 SELECT 之后執(zhí)行的,因為它引用了 SELECT 中的一個別名。但實際上不一定要這樣,數(shù)據(jù)庫引擎會把查詢重寫成這樣:
- SELECT
- CONCAT(first_name, ' ', last_name) AS full_name,
- count(*)
- FROM table
- GROUP BY CONCAT(first_name, ' ', last_name)
所以,這樣 GROUP BY 仍然先執(zhí)行。
另外,數(shù)據(jù)庫引擎還會做一系列檢查,確保 SELECT 和 GROUP BY 中的東西是有效的,所以會在生成執(zhí)行計劃之前對查詢做一次整體檢查。
數(shù)據(jù)庫很可能不按正常順序執(zhí)行查詢(優(yōu)化)
在實際當中,數(shù)據(jù)庫不一定會按照 JOIN、WHERE、GROUP BY 的順序來執(zhí)行查詢,因為它們會進行一系列優(yōu)化,把執(zhí)行順序打亂,從而讓查詢執(zhí)行得更快,只要不改變查詢結果。
這個查詢說明了為什么需要以不同的順序執(zhí)行查詢:
- SELECT * FROM
- dept d LEFT JOIN student s
- ON d.student_id = s.id
- WHERE s.name = '狼王'
如果只需要找出名字叫狼王學生信息,那就沒必要對兩張表的所有數(shù)據(jù)執(zhí)行左連接,在連接之前先進行過濾,這樣查詢會快得多,而且對于這個查詢來說,先執(zhí)行過濾并不會改變查詢結果。
好了。今天就說到這了,我還會不斷分享自己的所學所想,希望我們一起走在成功的道路上!