共計 3427 個字符，預計需要花費 9 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章主要介紹了 sql 語句在 mysql 中是怎么執行的，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。

一、mysql 架構分析

下面是 mysql 的一個簡要架構圖：

mysql 主要分為 Server 層和存儲引擎層

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

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

InnoDB 5.5.5 版本作為默認引擎。

連接器

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

查詢緩存

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

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

分析器

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

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

第二步，語法分析，主要就是判斷你輸入的 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 等執行過程分為兩類，一類對于查詢等過程如下：權限校驗 —》查詢緩存 —》分析器 —》優化器 —》權限校驗 —》執行器 —》引擎

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

感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“sql 語句在 mysql 中是怎么執行的”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!