MySql執行過程

一、MySql執行過程

1.1 說一下 MySQL 執行一條查詢語句的內部執行過程？

• 客戶端先通過連接器連接到 MySQL 服務器。

• 連接器權限驗證通過之後，先查詢是否有查詢緩存，如果有緩存（之前執行過此語句）則直接返回緩存數據，如果沒有緩存則進入分析器。

• 分析器會對查詢語句進行語法分析和詞法分析，判斷 SQL 語法是否正確，如果查詢語法錯誤會直接返回給客戶端錯誤信息，如果語法正確則進入優化器。

• 優化器是對查詢語句進行優化處理，例如一個表裏面有多個索引，優化器會判別哪個索引性能更好。

• 優化器執行完就進入執行器，執行器就開始執行語句進行查詢比對了，直到查詢到滿足條件的所有數據，然後進行返回。

  [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-KWQeIicm-1586874504228)(img\9565093-499036ec3eb24e1a…webp)]

1.2 MySQL主要分爲Server層和存儲引擎層

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

• 存儲引擎： 主要負責數據的存儲和讀取，採用可以替換的插件式架構，支持InnoDB、MyISAM、Memory等多個存儲引擎，其中InnoDB引擎有自有的日誌模塊redolog 模塊。

  InnoDB 5.5.5版本作爲默認引擎。

1.3 MySQL主要結構

• 連接器

主要負責用戶登錄數據庫，進行用戶的身份認證，包括校驗賬戶密碼，權限等操作，如果用戶賬戶密碼已通過，連接器會到權限表中查詢該用戶的所有權限，之後在這個連接裏的權限邏輯判斷都是會依賴此時讀取到的權限數據，也就是說，後續只要這個連接不斷開，即時管理員修改了該用戶的權限，該用戶也是不受影響的。

• 查詢緩存

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

Mysql 查詢不建議使用緩存，因爲對於經常更新的數據來說，緩存的有效時間太短了，往往帶來的效果並不好，對於不經常更新的數據來說，使用緩存還是可以的，Mysql 8.0 版本後刪除了緩存的功能，官方也是認爲該功能在實際的應用場景比較少，所以乾脆直接刪掉了。

• 分析器(解析器)

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

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

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

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

• 優化器

優化器的作用就是它認爲的最優的執行方案去執行（雖然有時候也不是最優），比如多個索引的時候該如何選擇索引，多表查詢的時候如何選擇關聯順序等。

• 執行器

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

二、語句分析

2.1 查詢語句

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

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的模式了，MyISAM引擎是沒有redo log的，那麼我們知道它是不支持事務的，所以並不是說只用一個日誌模塊不可以，只是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），這個日誌模塊所有執行引擎都可以共用。
• 引擎層是插件式的，目前主要包括，MyISAM,InnoDB,Memory等。
• sql等執行過程分爲兩類，一類對於查詢等過程如下：權限校驗->查詢緩存->分析器->優化器->權限校驗->執行器->引擎
  。
• 引擎層是插件式的，目前主要包括，MyISAM,InnoDB,Memory等。
• sql等執行過程分爲兩類，一類對於查詢等過程如下：權限校驗->查詢緩存->分析器->優化器->權限校驗->執行器->引擎
• 對於更新等語句執行流程如下：分析器->權限校驗->執行器->引擎—redo log prepare–>binlog->redo log commit