前言：
一直是想知道一條SQL語句是怎麼被執行的，它執行的順序是怎樣的，然後查看總結各方資料，就有了下面這一篇博文了。
本文將從MySQL總體架構--->查詢執行流程--->語句執行順序來探討一下其中的知識。
一、MySQL架構總覽：
架構最好看圖，再配上必要的說明文字。
下圖根據參考書籍中一圖爲原本，再在其上添加上了自己的理解。
從上圖中我們可以看到，整個架構分爲兩層，上層是MySQLD的被稱爲的‘SQL Layer’，下層是各種各樣對上提供接口的存儲引擎，被稱爲‘Storage Engine Layer’。其它各個模塊和組件，從名字上就可以簡單瞭解到它們的作用，這裏就不再累述了。
二、查詢執行流程
下面再向前走一些，容我根據自己的認識說一下查詢執行的流程是怎樣的：
1.連接
1.1客戶端發起一條Query請求，監聽客戶端的‘連接管理模塊’接收請求
1.2將請求轉發到‘連接進/線程模塊’
1.3調用‘用戶模塊’來進行授權檢查
1.4通過檢查後，‘連接進/線程模塊’從‘線程連接池’中取出空閒的被緩存的連接線程和客戶端請求對接，如果失敗則創建一個新的連接請求
2.處理
2.1先查詢緩存，檢查Query語句是否完全匹配，接着再檢查是否具有權限，都成功則直接取數據返回
2.2上一步有失敗則轉交給‘命令解析器’，經過詞法分析，語法分析後生成解析樹
2.3接下來是預處理階段，處理解析器無法解決的語義，檢查權限等，生成新的解析樹
2.4再轉交給對應的模塊處理
2.5如果是SELECT查詢還會經由‘查詢優化器’做大量的優化，生成執行計劃
2.6模塊收到請求後，通過‘訪問控制模塊’檢查所連接的用戶是否有訪問目標表和目標字段的權限
2.7有則調用‘表管理模塊’，先是查看table cache中是否存在，有則直接對應的表和獲取鎖，否則重新打開表文件
2.8根據表的meta數據，獲取表的存儲引擎類型等信息，通過接口調用對應的存儲引擎處理
2.9上述過程中產生數據變化的時候，若打開日誌功能，則會記錄到相應二進制日誌文件中
3.結果
3.1Query請求完成後，將結果集返回給‘連接進/線程模塊’
3.2返回的也可以是相應的狀態標識，如成功或失敗等
3.3‘連接進/線程模塊’進行後續的清理工作，並繼續等待請求或斷開與客戶端的連接
一圖小總結
三、SQL解析順序
接下來再走一步，讓我們看看一條SQL語句的前世今生。
首先看一下示例語句
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 <left_table>
ON <join_condition>
<join_type> JOIN <right_table>
WHERE <where_condition>
GROUP BY <group_by_list>
HAVING <having_condition>
SELECT
DISTINCT <select_list>
ORDER BY <order_by_condition>
LIMIT <limit_number>
雖然自己沒想到是這樣的，不過一看還是很自然和諧的，從哪裏獲取，不斷的過濾條件，要選擇一樣或不一樣的，排好序，那才知道要取前幾條呢。
既然如此了，那就讓我們一步步來看看其中的細節吧。
準備工作
1.創建測試數據庫
create database test
2.創建測試表
CREATE TABLE `score` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`uid` char(10) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`score` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
3.插入數據 同名同姓的多個張三參加了多次考試，一個打醬油的還忘記在試卷上寫名字了
INSERT INTO user (name)
VALUES
('張三'),('pendant59'),('張三'),('張三');
INSERT INTO score ( uid,score )
VALUES
( '1', 99 ),( '1', 69 ),
( '2', 59 ),( '2', 80 ),
( '2', 99 ),( '3', 75 ),
( '', 59);
4.最後想要的結果： 讓我們找出得分最高的張三的ID和他考試的總次數
SELECT
u.`id`,
u.`name`,
count( s.id ) AS total,
max( s.score ) AS max_score
FROM
`user` AS u
LEFT JOIN score AS s ON u.`id` = s.`uid`
WHERE
u.NAME = '張三'
GROUP BY
u.id
HAVING
max(s.score) > 0
ORDER BY
max_score DESC
LIMIT 1;
現在開始SQL解析之旅吧！
主表：user , 關聯表 score
1. FROM
當涉及多個表的時候，左邊表的輸出會作爲右邊表的輸入，之後會生成一個虛擬表VT1。
(1-J1) 笛卡爾積
計算兩個相關聯表的笛卡爾積(CROSS JOIN) ，生成虛擬表VT1-J1。28條記錄 u:4 s:7 4*7=28
SELECT * FROM `user`, score
目標sql 生成的 VT1-J1 表：
(1-J2) on 是爲 join 服務的，外聯接下，關注的是關聯表的數據，內連接(inner join)則關注關聯表和主表的數據
1. on 的目的 是 基於虛擬表VT1-J1這一個虛擬表進行過濾，過濾出所有滿足on 條件的列，生成虛擬表VT1-J2。
2. 外聯接 on 關注的是 關聯表, 雖然在on中添加了 u.name 限制條件，但是結果還是返回了主表中所有數據：
3. 外聯接 on 是多條件，仍然只對關聯表進行篩選：
藍色框是關聯表的數據 pendant59已經被剔除，所以紅色框內主表中pendant59對應的關聯表中的數據是空
inner join ，不需要添加外部列，主表和關聯表在on的基礎上 取交集 (可以看作是目標sql查詢生成的 VT1-J2 表，實際上不是，但是 on 和 添加外部列 沒辦法拆開顯示)
因爲目標sql是 left join，需要添加外部列，所以會有J3表
(1-J3) 添加外部列（外連接）
如果使用了外連接(LEFT,RIGHT,FULL)，主表（user）中所有列會被加入到VT1-J2中，作爲外部行，生成虛擬表VT1-J3。
目標sql查詢結果 VT1 表 ： 最後id爲 4的 張三 是添加的外部列 （這樣主表所有的列都在VT1中了）
下面從網上找到一張很形象的關於‘SQL JOINS'的解釋圖，如若侵犯了你的權益，請勞煩告知刪除，謝謝。
2. WHERE
1. 對上一步生成的臨時表VT1進行過濾（這時只針對VT1表內的數據，會把VT1中不符合where 條件的記錄全部過濾掉），滿足WHERE子句的列被插入到VT2表中。
注意：
此時因爲分組，不能使用聚合運算；也不能使用SELECT中創建的別名:
更改sql 查詢的字段，統計記錄條數並設置別名
目標sql查詢結果 VT2 表： 已將 VT1中 name != 張三的記錄排除了
Where 和 On 的比較：
在外連接的情況下 on 關注的是關聯表，篩選關聯表的數據，目的是生成虛擬表 VT1，
在內連接的情況下 on 關注的是關聯表 和 主表，篩選關聯表和主表的數據，目的是生成虛擬表 VT1，
where 關注的是 VT1 虛擬表， 篩選虛擬表VT1中的數據服務，目的是生成虛擬表VT2。
on 和 where 關注的對象不同，目的也不同。
3. GROUP BY
這個子句會把VT2中生成的表按照GROUP BY中的列進行分組。生成VT3表。
注意：
其後處理過程的語句，如SELECT,HAVING，所用到的列必須包含在GROUP BY中，對於沒有出現的，得用聚合函數；
原因：
GROUP BY改變了對錶的引用，將其轉換爲新的引用方式，能夠對其進行下一級邏輯操作的列會減少；
原作者的理解是：
根據分組字段，將具有相同分組字段的記錄歸併成一條記錄，因爲每一個分組只能返回一條記錄，除非是被過濾掉了，而不在分組字段裏面的字段可能會有多個值，多個值是無法放進一條記錄的，所以必須通過聚合函數將這些具有多值的列轉換成單值；
這裏的 select * 就是 就是隻通過group by 聚合後的數據生成的VT3表包含的字段，但是因爲包含 非聚合的 s.id 所以無法生成VT3表，於是會拋出異常。
可以通過去掉配置文件 中sql_mode 選項值 ONLY_FULL_GROUP_BY 使mysql 支持當前sql，但是不推薦，還是按標準的方式書寫。
（原文作者可以正常查詢，博文發表時間是15年，應該是5.7以下版本，默認就沒有ONLY_FULL_GROUP_BY）
這裏報錯說 包含非聚合的s.id 跟原文作者的理解是一樣的，在上面的VT2表中，
s.id，s.score 都是 有多個不同值，在group by 的時候無法合併，所以要想select 中包含 s.id 和 s.score 就要用聚合函數來使他們變成一個值，然後group by 才能生成一條記錄（聚合函數：max(), min(),count(),sum(),avg()）
這個是不包含有多個值的查詢（group by 可以 u.id 正常分組，返回唯一記錄），查詢正常，結果也生成了當前查詢對應的VT3表
經過聚合函數處理後的 s.id 生成了新的唯一字段 也可以正常查詢了，結果也生成了當前查詢對應的VT3表（你也可以用sum,avg 等聚合函數，這裏是爲了目標sql）
目標sql查詢結果 VT3 表：
吶吶吶，這裏答案就已經呼之欲出了 （因爲sql_mode的配置原因，跟原作者查詢的sql不一樣，原作者可以select * ）。
4. HAVING
這個子句對VT3表中的不同的組進行過濾，只作用於分組後的數據，滿足HAVING條件的子句被加入到VT4表中。
接下來就意思一下 來個having( 關於 having 後面跟不跟select 的別名 詳見文末補充)，對VT3的記錄進行篩選生成VT4
目標sql查詢結果 VT4 表：
（因爲sql_mode的配置原因，跟原作者查詢的sql不一樣，原作者可以select * ）
5. SELECT
這個子句對SELECT子句中的元素進行處理，生成VT5表。
(5-J1)計算表達式 計算SELECT 子句中的表達式，生成VT5-J1
(5-J2)DISTINCT (如果有用到)
尋找VT5-1中的重複列，並刪掉，生成VT5-J2
如果在查詢中指定了DISTINCT子句，則會創建一張內存臨時表（如果內存放不下，就需要存放在硬盤了）。這張臨時表的表結構和上一步產生的虛擬表VT5是一樣的，不同的是對進行DISTINCT操作的列增加了一個唯一索引，以此來除重複數據。
目標sql查詢結果 VT5 表：
這裏和having 生成的表其實是一樣的 因爲select 的已經在vt4表中了 （因爲sql_mode的配置原因，跟原作者查詢的sql不一樣，原作者可以select * 所以可以把 VT4 和VT5 分開展示）
6.ORDER BY
從VT5-J2中的表中，根據ORDER BY 子句的條件對結果進行排序，生成VT6表。
注意：
唯一可使用SELECT中別名的地方；
目標sql查詢結果 VT6 表：
7.LIMIT
LIMIT子句從上一步得到的VT6虛擬表中選出從指定位置開始的指定行數據。
注意：
offset和rows的正負帶來的影響；
當偏移量很大時效率是很低的，可以使用 inner join 優化：
例如 select * from test a inner join (select id from test where val=4 limit 300000,5) b on a.id=b.id; # join裏面不要用 *
參考鏈接
https://www.cnblogs.com/zhangyachen/p/8030252.html
https://github.com/zhangyachen/zhangyachen.github.io/issues/117
至此SQL的解析之旅就結束了，上圖總結一下：
參考書籍：
《MySQL性能調優與架構實踐》
《MySQL技術內幕：SQL編程》
補充：
1. 關於having後面是否可以跟 select中定義的別名的問題，經測試，Mysql 5.7.x版本 允許在having condition中使用select list中的alias, （配置文件中的 sql_mode 包含 ONLY_FULL_GROUP_BY 依然可以）, 但是標準的sql語句是不能在having後面使用select 中定義的別名 https://www.w3school.com.cn/sql/sql_having.asp
看了原作者的文章，又用了四五個小時自己過了一遍，添加了一些補充說明，收穫頗多。撒花~