查詢語句：許可權校驗–>快取查詢–>分析器–>優化器–>執行器–>許可權校驗–>執行器–>引擎。
更新語句：分析器–>許可權校驗–>執行器–>引擎–>redolog prepare–>binlog–>redolog commit。
mysql主要分為2部分：server層和儲存引擎層。
查詢快取：執行查詢語句的時候，會先查詢快取（mysql8.0版本後移除）
1）該步驟不做語法分析。
2）mysql收到語句後，通過命令分發器判斷是否是查詢語句。
3）如果是在開啟查詢快取的情況下，先查詢快取中查詢該sql是否完全匹配，快取存放在乙個引用表（key-value）中，通過乙個雜湊值引用，雜湊值key是查詢預計，包含查詢本身、當前要查詢的資料庫、客戶端協議的版本等一些其他可能影響返回結果的資訊，當判斷快取是否命中時，mysql不會進行解析查詢語句，而是直接使用sql語句和客戶端傳送夠來的其他原始資訊。因此任何字元上的不同，比如空格、注釋等都會導致快取的不命中,如果匹配，驗證當前使用者是否具備查詢許可權，如果許可權驗證通過，直接返回結果集（value）給客戶端，如果不匹配則繼續向下執行。
4）新版本去除快取的原因：查詢快取失效在實際業務場景中可能會很頻繁，因為對乙個表更新這個表的所有查詢快取都會被清空。對於不經常更新的資料來說，使用快取還是可以的。
分析器：沒有命中快取的話，sql語句就會經過分析器，檢查語句語法是否正確。
1）提取關鍵字，提取查詢表、欄位名、查詢條件等。
2）判斷是否符合mysql語法。
優化器：按照mysql認為最優的方案執行。
執行器：執行語句，然後從儲存引擎返回資料。
執行前還需要判斷使用者許可權，如果有許可權就呼叫引擎的介面返回執行結果；如果沒有許可權就會返回錯誤資訊。
執行語句更新的時候需要引入日誌模組。mysql自帶日誌模組binlog（歸檔日誌），所有儲存引擎都可以使用；innodb引擎也自帶日誌模組redolog（重做日誌）。一條更新語句流程我們可以歸納如下：
1）查詢該條資料是否有快取，如果有則用快取。
2）拿到查詢語句，呼叫引擎介面，寫入資料，innodb引擎把資料儲存在記憶體中，同時記錄redolog，此時redolog進入prepare狀態，然後告訴執行器，執行完成了，可以提交。
3）執行器收到通知後記錄binlog，呼叫引擎介面提交redolog為提交狀態。
4）更新完成。
問1：為什麼要用兩個日誌模組，用乙個日誌模組不行嗎?
最開始 mysql 並沒與 innodb 引擎( innodb 引擎是其他公司以外掛程式形式插入 mysql 的) ，mysql 自帶的引擎是 myisam，但是我們知道 redo log 是 innodb 引擎特有的，其他儲存引擎都沒有，這就導致會沒有 crash-safe 的能力(crash-safe 的能力即使資料庫發生異常重啟，之前提交的記錄都不會丟失)，binlog 日誌只能用來歸檔。
問2：如何通過redolog和binlog保證資料的一致性？
由mysql的處理機制保證。
1）判斷redolog是否完整，如果完整就立即提交。
2）如果redolog只是預提交但不是commit狀態，需要判斷binlog是否完整，如果完整就提交redolog，不完整就回滾事務。
MySQL語句執行過程
目錄平常我們看到的只是一條語句執行出來的結果，並不知道中間發生了什麼，今天就來 一下，mysql語句的執行過程。每次使用mysql會先連線到資料庫上面，聯結器負責跟客戶端進行連線 mysql u root p然後根據密碼，判斷我登陸進去會有什麼許可權，並分配許可權給我 通過show processl...
mysql 語句執行的過程
實際上mysql執行的每一步都比較複雜，具體的過程如下 1 mysql客戶端和伺服器通訊 mysql客戶端和伺服器之間的通訊協議是 半雙工 的，這意味著，在任何乙個時刻，要麼由伺服器向客戶端傳送資料，要麼由客戶端向伺服器傳送資料，這兩個動作不能同時發生。這種協議讓mysql通訊簡單快速，但也限制了m...
MySQL查詢語句執行過程
先上圖 眾所周知在mysql資料庫應用中查詢請求是使用最多的，假設我們輸入下面的sql，通過客戶端請求mysql伺服器，會得到乙個包含user的結果集。但是，其中mysql的處理過程我們並不了解，那麼下面就讓我們一起看看在查詢請求前後mysql服務端發生了些什麼吧。如上圖所示，整張圖由三部分組成，從...