MySQL 執行語句分析

查詢語句

sql 語句分為兩種，一種是查詢，一種是更新（增加，更新，刪除）。先分析下查詢語句，語句如下：

select * from tb_student  a where a.age = '18' and a.name = '張三';

結合上面的說明，我們分析下這個語句的執行流程：

先檢查該語句是否有許可權，如果沒有許可權，直接返回錯誤資訊，如果有許可權，在 mysql8.0 版本以前，會先查詢快取，以這條 sql 語句為 key 在記憶體中查詢是否有結果，如果有直接快取，則返回；如果沒有，執行下一步。

接下來就是優化器進行確定執行方案，上面的 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 兩階段提交的方式就不一樣了，寫完 binglog 後，然後再提交 redo log 就會防止出現上述的問題，從而保證了資料的一致性。那麼問題來了，有沒有乙個極端的情況呢？假設 redo log 處於預提交狀態，binglog 也已經寫完了，這個時候發生了異常重啟會怎麼樣呢？這個就要依賴於 mysql 的處理機制了，mysql 的處理過程如下：

這樣就解決了資料一致性的問題。

MySQL 執行語句分析

mysql 語句分析 MySQL語句執行分析

mysql 語句在哪執行 MySQL語句執行過程

mysql語句執行時間分析

MySQL 執行語句分析

mysql 語句分析 MySQL語句執行分析

mysql 語句在哪執行 MySQL語句執行過程

mysql語句執行時間分析

相關推薦