小夥伴想精準查找本身想看的MySQL文章？喏 → MySQL專欄目錄 | 點擊這裏sql

SQL 查詢的執行順序是怎樣的？數據庫

好像這個問題應該很好回答，畢竟本身已經寫了無數個 SQL 查詢了，有一些還很複雜的。還裝不了這個逼了？！函數

但事實是，我仍然很難確切地說出它的順序是怎樣的。學習

言歸正傳，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>

然而其執行順序倒是：url

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
<行數限制>spa

其實，引擎在執行上述每一步時，都會在內存中造成一張虛擬表，而後對虛擬表進行後續操做，並釋放沒用的虛擬表的內存，以此類推。

具體解釋：（注：下面「VT」表示 → 虛擬表 virtual ）.net

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；

須要注意的是：code

group by條件中，每一個列必須是有效列，不能是聚合函數；

null值也會做爲一個分組返回；

除了聚合函數，select子句中的列必須在group by條件中；

上述內容讓咱們知道一個查詢會返回什麼，同時，也回答瞭如下這些問題：blog

能夠在 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 中的一個別名。但實際上不必定要這樣，數據庫引擎會把查詢重寫成這樣↓↓↓：

SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)
FROM table
GROUP BY CONCAT(first_name, ' ', last_name)

因此，這樣 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 = '陳哈哈'

若是隻須要找出名字叫「陳哈哈」的學生信息，那就不必對兩張表的全部數據執行左鏈接，在鏈接以前先進行過濾，這樣查詢會快得多，並且對於這個查詢來講，先執行過濾並不會改變查詢結果。

能看到這裏的朋友都是有緣人了，爲你的學習力點贊！但願大佬也能爲小弟點贊支持一下哦！

本文同步分享在博客「_陳哈哈」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。

SQL 查詢語句先執行 SELECT？兄弟你認真的麼？

SQL中的別名會影響SQL執行順序麼？

數據庫極可能不按正常順序執行查詢（優化）