一條SQL語句在MySQL中如何執行的

本篇文章會分析一個 sql 語句在 MySQL 中的執行流程，包括 sql 的查詢在 MySQL 內部會怎麼流轉，sql 語句的更新是怎麼完成的。

在分析以前我會先帶着你看看 MySQL 的基礎架構，知道了 MySQL 由那些組件組成以及這些組件的做用是什麼，能夠幫助咱們理解和解決這些問題。

一 MySQL 基礎架構分析

1.1 MySQL 基本架構概覽

下圖是 MySQL 的一個簡要架構圖，從下圖你能夠很清晰的看到用戶的 SQL 語句在 MySQL 內部是如何執行的。

先簡單介紹一下下圖涉及的一些組件的基本做用幫助你們理解這幅圖，在 1.2 節中會詳細介紹到這些組件的做用。

•鏈接器： 身份認證和權限相關(登陸 MySQL 的時候)。

•查詢緩存: 執行查詢語句的時候，會先查詢緩存（MySQL 8.0 版本後移除，由於這個功能不太實用）。

•分析器: 沒有命中緩存的話，SQL 語句就會通過分析器，分析器說白了就是要先看你的 SQL 語句要幹嗎，再檢查你的 SQL 語句語法是否正確。

•優化器： 按照 MySQL 認爲最優的方案去執行。

•執行器: 執行語句，而後從存儲引擎返回數據。

一條SQL語句在MySQL中如何執行的
簡單來講 MySQL 主要分爲 Server 層和存儲引擎層：

•Server 層：主要包括鏈接器、查詢緩存、分析器、優化器、執行器等，全部跨存儲引擎的功能都在這一層實現，好比存儲過程、觸發器、視圖，函數等，還有一個通用的日誌模塊 binglog 日誌模塊。

•存儲引擎： 主要負責數據的存儲和讀取，採用能夠替換的插件式架構，支持 InnoDB、MyISAM、Memory 等多個存儲引擎，其中 InnoDB 引擎有自有的日誌模塊 redolog 模塊。如今最經常使用的存儲引擎是 InnoDB，它從 MySQL 5.5.5 版本開始就被當作默認存儲引擎了。

1.2 Server 層基本組件介紹

1) 鏈接器

鏈接器主要和身份認證和權限相關的功能相關，就比如一個級別很高的門衛同樣。

主要負責用戶登陸數據庫，進行用戶的身份認證，包括校驗帳戶密碼，權限等操做，若是用戶帳戶密碼已經過，鏈接器會到權限表中查詢該用戶的全部權限，以後在這個鏈接裏的權限邏輯判斷都是會依賴此時讀取到的權限數據，也就是說，後續只要這個鏈接不斷開，即時管理員修改了該用戶的權限，該用戶也是不受影響的。

2) 查詢緩存(MySQL 8.0 版本後移除)

查詢緩存主要用來緩存咱們所執行的 SELECT 語句以及該語句的結果集。

鏈接創建後，執行查詢語句的時候，會先查詢緩存，MySQL 會先校驗這個 sql 是否執行過，以 Key-Value 的形式緩存在內存中，Key 是查詢預計，Value 是結果集。若是緩存 key 被命中，就會直接返回給客戶端，若是沒有命中，就會執行後續的操做，完成後也會把結果緩存起來，方便下一次調用。固然在真正執行緩存查詢的時候仍是會校驗用戶的權限，是否有該表的查詢條件。

MySQL 查詢不建議使用緩存，由於查詢緩存失效在實際業務場景中可能會很是頻繁，假如你對一個表更新的話，這個表上的全部的查詢緩存都會被清空。對於不常常更新的數據來講，使用緩存仍是能夠的。

因此，通常在大多數狀況下咱們都是不推薦去使用查詢緩存的。

MySQL 8.0 版本後刪除了緩存的功能，官方也是認爲該功能在實際的應用場景比較少，因此乾脆直接刪掉了。

3) 分析器

MySQL 沒有命中緩存，那麼就會進入分析器，分析器主要是用來分析 SQL 語句是來幹嗎的，分析器也會分爲幾步：

第一步，詞法分析，一條 SQL 語句有多個字符串組成，首先要提取關鍵字，好比 select，提出查詢的表，提出字段名，提出查詢條件等等。作完這些操做後，就會進入第二步。

第二步，語法分析，主要就是判斷你輸入的 sql 是否正確，是否符合 MySQL 的語法。

完成這 2 步以後，MySQL 就準備開始執行了，可是如何執行，怎麼執行是最好的結果呢？這個時候就須要優化器上場了。

4) 優化器

優化器的做用就是它認爲的最優的執行方案去執行（有時候可能也不是最優，這篇文章涉及對這部分知識的深刻講解），好比多個索引的時候該如何選擇索引，多表查詢的時候如何選擇關聯順序等。

能夠說，通過了優化器以後能夠說這個語句具體該如何執行就已經定下來。

5) 執行器

當選擇了執行方案後，MySQL 就準備開始執行了，首先執行前會校驗該用戶有沒有權限，若是沒有權限，就會返回錯誤信息，若是有權限，就會去調用引擎的接口，返回接口執行的結果。

二 語句分析

2.1 查詢語句

說了以上這麼多，那麼究竟一條 sql 語句是如何執行的呢？其實咱們的 sql 能夠分爲兩種，一種是查詢，一種是更新（增長，更新，刪除）。咱們先分析下查詢語句，語句以下：

select * from tb_student A where A.age='18' and A.name=' 張三 ';
結合上面的說明，咱們分析下這個語句的執行流程：

先檢查該語句是否有權限，若是沒有權限，直接返回錯誤信息，若是有權限，在 MySQL8.0 版本之前，會先查詢緩存，以這條 sql 語句爲 key 在內存中查詢是否有結果，若是有直接緩存，若是沒有，執行下一步。
經過分析器進行詞法分析，提取 sql 語句的關鍵元素，好比提取上面這個語句是查詢 select，提取須要查詢的表名爲 tb_student,須要查詢全部的列，查詢條件是這個表的 id='1'。而後判斷這個 sql 語句是否有語法錯誤，好比關鍵詞是否正確等等，若是檢查沒問題就執行下一步。
接下來就是優化器進行肯定執行方案，上面的 sql 語句，能夠有兩種執行方案：
a.先查詢學生表中姓名爲「張三」的學生，而後判斷是否年齡是 18。 b.先找出學生中年齡 18 歲的學生，而後再查詢姓名爲「張三」的學生。
那麼優化器根據本身的優化算法進行選擇執行效率最好的一個方案（優化器認爲，有時候不必定最好）。那麼確認了執行計劃後就準備開始執行了。

進行權限校驗，若是沒有權限就會返回錯誤信息，若是有權限就會調用數據庫引擎接口，返回引擎的執行結果。

2.2 更新語句

以上就是一條查詢 sql 的執行流程，那麼接下來咱們看看一條更新語句如何執行的呢？sql 語句以下：

update tb_student A set A.age='19' where A.name=' 張三 ';
咱們來給張三修改下年齡，在實際數據庫確定不會設置年齡這個字段的，否則要被技術負責人打的。其實條語句也基本上會沿着上一個查詢的流程走，只不過執行更新的時候確定要記錄日誌啦，這就會引入日誌模塊了，MySQL 自帶的日誌模塊式 binlog（歸檔日誌） ，全部的存儲引擎均可以使用，咱們經常使用的 InnoDB 引擎還自帶了一個日誌模塊 redo log（重作日誌），咱們就以 InnoDB 模式下來探討這個語句的執行流程。流程以下：

•先查詢到張三這一條數據，若是有緩存，也是會用到緩存。

•而後拿到查詢的語句，把 age 改成 19，而後調用引擎 API 接口，寫入這一行數據，InnoDB 引擎把數據保存在內存中，同時記錄 redo log，此時 redo log 進入 prepare 狀態，而後告訴執行器，執行完成了，隨時能夠提交。

•執行器收到通知後記錄 binlog，而後調用引擎接口，提交 redo log 爲提交狀態。

•更新完成。

這裏確定有同窗會問，爲何要用兩個日誌模塊，用一個日誌模塊不行嗎?

這是由於最開始 MySQL 並沒與 InnoDB 引擎( InnoDB 引擎是其餘公司以插件形式插入 MySQL 的) ，MySQL 自帶的引擎是 MyISAM，可是咱們知道 redo log 是 InnoDB 引擎特有的，其餘存儲引擎都沒有，這就致使會沒有 crash-safe 的能力(crash-safe 的能力即便數據庫發生異常重啓，以前提交的記錄都不會丟失)，binlog 日誌只能用來歸檔。

並非說只用一個日誌模塊不能夠，只是 InnoDB 引擎就是經過 redo log 來支持事務的。那麼，又會有同窗問，我用兩個日誌模塊，可是不要這麼複雜行不行，爲何 redo log 要引入 prepare 預提交狀態？這裏咱們用反證法來講明下爲何要這麼作？

•先寫 redo log 直接提交，而後寫 binlog，假設寫完 redo log 後，機器掛了，binlog 日誌沒有被寫入，那麼機器重啓後，這臺機器會經過 redo log 恢復數據，可是這個時候 bingog 並無記錄該數據，後續進行機器備份的時候，就會丟失這一條數據，同時主從同步也會丟失這一條數據。

•先寫 binlog，而後寫 redo log，假設寫完了 binlog，機器異常重啓了，因爲沒有 redo log，本機是沒法恢復這一條記錄的，可是 binlog 又有記錄，那麼和上面一樣的道理，就會產生數據不一致的狀況。

若是採用 redo log 兩階段提交的方式就不同了，寫完 binglog 後，而後再提交 redo log 就會防止出現上述的問題，從而保證了數據的一致性。那麼問題來了，有沒有一個極端的狀況呢？假設 redo log 處於預提交狀態，binglog 也已經寫完了，這個時候發生了異常重啓會怎麼樣呢？ 這個就要依賴於 MySQL 的處理機制了，MySQL 的處理過程以下：

•判斷 redo log 是否完整，若是判斷是完整的，就當即提交。

•若是 redo log 只是預提交但不是 commit 狀態，這個時候就會去判斷 binlog 是否完整，若是完整就提交 redo log, 不完整就回滾事務。

這樣就解決了數據一致性的問題。

​三 總結

•MySQL 主要分爲 Server 層和引擎層，Server 層主要包括鏈接器、查詢緩存、分析器、優化器、執行器，同時還有一個日誌模塊（binlog），這個日誌模塊全部執行引擎均可以共用,redolog 只有 InnoDB 有。

•引擎層是插件式的，目前主要包括，MyISAM,InnoDB,Memory 等。

•SQL 等執行過程分爲兩類，一類對於查詢等過程以下：權限校驗---》查詢緩存---》分析器---》優化器---》權限校驗---》執行器---》引擎

•對於更新等語句執行流程以下：分析器----》權限校驗----》執行器---》引擎---redo log prepare---》binlog---》redo log commit