1、MySQL基本結構分析 1.1 、基本框架 下圖是 MySQL 的一個簡要架構圖，從下圖你可以很清晰的看到使用者的 SQL 語句在 MySQL 內部是如何執行的。 如上圖所示，MySQL伺服器邏輯架構從上往下可以分為三層： (1)第一層：處理客戶端連線、授權認證等。 (2)第二層：伺服器層，負責查詢語句的解析、優化、快取以及內建函式的實現、儲存過程等。 (3)第三層：儲存引擎，負責MySQL中資料的儲存和提取。MySQL中伺服器層不管理事務，事務是由儲存引擎實現的。MySQL支援事務的儲存引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最為廣泛；其他儲存引擎不支援事務，如MyIsam、Memory等。 其中：

• 聯結器： 身份認證和許可權相關(登入 MySQL 的時候)。
• 查詢快取: 執行查詢語句的時候，會先查詢快取（MySQL 8.0 版本後移除，因為這個功能不太實用）。
• 分析器：沒有命中快取的話，SQL 語句就會經過分析器，分析器說白了就是要先看你的 SQL 語句要幹嘛，再檢查你的 SQL 語句語法是否正確。
• 優化器：按照 MySQL 認為最優的方案去執行。
• 執行器：執行語句，然後從儲存引擎返回資料。

很明顯，最重要的是分析器，優化器和執行器。 MySQL 主要分為 Server 層和儲存引擎層：

• Server 層：主要包括聯結器、查詢快取、分析器、優化器、執行器等，所有跨儲存引擎的功能都在這一層實現，比如儲存過程、觸發器、檢視，函式等，還有一個通用的日誌模組 binlog 日誌模組。
• 儲存引擎： 主要負責資料的儲存和讀取，採用可以替換的外掛式架構，支援 InnoDB、MyISAM、Memory 等多個儲存引擎，其中 InnoDB 引擎自有的日誌模組 redolog（重做日誌） 模組。現在最常用的儲存引擎是 InnoDB，它從 MySQL 5.5.5 版本開始就被當做預設儲存引擎了。InnoDB的整體架構分為兩個部分：記憶體架構和磁碟架構:

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 語句分析 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（歸檔日誌，在Server層） ，所有的儲存引擎都可以使用，我們常用的 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, 不完整就回滾事務。

這樣就解決了資料一致性的問題。 3、日誌模組 3.1、redo log 在 MySQL 中，如果每一次的更新操作都需要寫進磁碟，然後磁碟也要找到對應的那條記錄，然後再更新，整個過程 IO 成本、查詢成本都很高。為了解決這個問題，MySQL 的設計者就採用了日誌（redo log）來提升更新效率。 Redo log記錄的是新資料的備份。在事務提交前，只要將Redo Log持久化即可，不需要將資料持久化。當系統崩潰時，雖然資料沒有持久化， 但是RedoLog已經持久化。系統可以根據RedoLog的內容，將所有資料恢復到最新的狀態。 InnoDB有buffer pool（簡稱bp）。bp是資料庫頁面的快取，對InnoDB的任何修改操作都會首先在bp的page上進行，然後這樣的頁面將被標記為dirty並被放到專門的flush list上，後續將由master thread或專門的刷髒執行緒階段性的將這些頁面寫入磁碟（disk or ssd）。這樣的好處是避免每次寫操作都操作磁碟導致大量的隨機IO，階段性的刷髒可以將多次對頁面的修改merge成一次IO操作，同時非同步寫入也降低了訪問的時延。然而，如果在dirty page還未刷入磁碟時，server非正常關閉，這些修改操作將會丟失，如果寫入操作正在進行，甚至會由於損壞資料檔案導致資料庫不可用。為了避免上述問題的發生，Innodb將所有對頁面的修改操作寫入一個專門的檔案，並在資料庫啟動時從此檔案進行恢復操作，這個檔案就是redo log file。這樣的技術推遲了bp頁面的重新整理，從而提升了資料庫的吞吐，有效的降低了訪問時延。帶來的問題是額外的寫redo log操作的開銷（順序IO，當然很快），以及資料庫啟動時恢復操作所需的時間。 日誌和磁碟配合的整個過程，其實就是 MySQL 裡的 WAL 技術，WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日誌，再寫磁碟。 具體來說，當有一條記錄需要更新的時候，InnoDB 引擎就會先把記錄寫到 redo log（redolog buffer）裡面，並更新記憶體（buffer pool），這個時候更新就算完成了。同時，InnoDB 引擎會在適當的時候（如系統空閒時），將這個操作記錄更新到磁盤裡面（刷髒頁）。 redo log 是InnoDB儲存引擎層的日誌，又稱重做日誌檔案，redo log是迴圈寫的，redo log不是記錄資料頁更新之後的狀態，而是記錄這個頁做了什麼改動。redo log 是固定大小的，比如可以配置為一組 4 個檔案，每個檔案的大小是 1GB，那麼日誌總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭迴圈寫，如下圖所示。 圖中展示了一組 4 個檔案的 redo log 日誌，check point 是當前要擦除的位置，擦除記錄前需要先把對應的資料落盤（更新記憶體頁，等待刷髒頁）。write pos 到 checkpoint 之間的部分可以用來記錄新的操作，如果 write pos 和 checkpoint 相遇，說明 redolog 已滿，這個時候資料庫停止進行資料庫更新語句的執行，轉而進行 redo log 日誌同步到磁碟中。checkpoint 到 write pos 之間的部分等待落盤（先更新記憶體頁，然後等待刷髒頁）。有了 redo log 日誌，那麼在資料庫進行異常重啟的時候，可以根據 redo log 日誌進行恢復，也就達到了 crash-safe。 redo log 用於保證crash-safe能力。innodb_flush_log_at_trx_commit 這個引數設定成 1 的時候，表示每次事務的 redo log 都直接持久化到磁碟。這個引數建議設定成 1，這樣可以保證 MySQL 異常重啟之後資料不丟失。 3.2、binlog MySQL 整體來看，其實就有兩塊：一塊是 Server 層，它主要做的是 MySQL 功能層面的事情；還有一塊是引擎層，負責儲存相關的具體事宜。redo log 是 InnoDB 引擎特有的日誌，而 Server 層也有自己的日誌，稱為 binlog（歸檔日誌）。binlog 屬於邏輯日誌，是以二進位制的形式記錄的是這個語句的原始邏輯，依靠 binlog 是沒有 crash-safe 能力的。 binlog記錄了資料庫上的所有改變，並以二進位制的形式儲存在磁碟中；它可以用來檢視資料庫的變更歷史、資料庫增量備份和恢復、Mysql的複製（主從資料庫的複製）。語句以“事件”的形式儲存，它描述資料更改。因為有了資料更新的binlog，所以可以用於實時備份，與master/slave複製。高可用與資料恢復。

• 恢復使能夠最大可能地更新資料庫，因為二進位制日誌包含備份後進行的所有更新。
• 在主複製伺服器上記錄所有將傳送給從伺服器的語句。

binlog有三種格式：Statement、Row以及Mixed。從安全性來看，ROW（最安全）、MIXED（不推薦）、STATEMENT（不推薦）。 Statement:每一條會修改資料的sql都會記錄在binlog中。在5.6.24中預設格式。 優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高效能。 缺點：由於記錄的只是執行語句，為了這些語句能在slave上正確執行，因此還必須記錄每條語句在執行的時候的一些相關資訊，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql的複製,像一些特定函式功能，slave可與master上要保持一致會有很多相關問題。 ps：相比row能節約多少效能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO效能問題。 Row:5.1.5版本的MySQL才開始支援row level的複製,它不記錄sql語句上下文相關資訊，僅儲存哪條記錄被修改。 優點：binlog中可以不記錄執行的sql語句的上下文相關的資訊，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。而且不會出現某些特定情況下的儲存過程，或function，以及trigger的呼叫和觸發無法被正確複製的問題. 缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。 ps:新版本的MySQL中對row level模式也被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果sql語句確實就是update或者delete等修改資料的語句，那麼還是會記錄所有行的變更。 Mixed:從5.1.8版本開始，MySQL提供了Mixed格式，實際上就是Statement與Row的結合。 在Mixed模式下，一般的語句修改使用statment格式儲存binlog，如一些函式，statement無法完成主從複製的操作，則採用row格式儲存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。 1、redo log 和 binlog 區別： redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。 redo log 是物理日誌，記錄的是在某個資料頁上做了什麼修改；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯。 redo log 是迴圈寫的，空間固定會用完；binlog 是可以追加寫入的。追加寫是指 binlog 檔案寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。 有了對這兩個日誌的概念性理解後，再來看執行器和 InnoDB 引擎在執行這個 update 語句時的內部流程。 UPDATE T SET c = c + 1 WHERE ID = 2; 1、執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜尋找到這一行。如果 ID=2 這一行所在的資料頁本來就在記憶體中，就直接返回給執行器；否則，需要先從磁碟讀入記憶體，然後再返回。 2、執行器拿到引擎給的行資料，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的一行資料，再呼叫引擎介面寫入這行新資料。 3、引擎將這行新資料更新到記憶體（InnoDB Buffer Pool）中，同時將這個更新操作記錄到 redo log 裡面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。 4、執行器生成這個操作的 binlog，並把 binlog 寫入磁碟。 5、執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。 其中將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是兩階段提交（2PC）。 2、redo log 和 binlog 是怎麼關聯起來的? redo log 和 binlog 有一個共同的資料欄位，叫 XID。崩潰恢復的時候，會按順序掃描 redo log： 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交； 如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務。 3、MySQL 怎麼知道 binlog 是完整的? 一個事務的 binlog 是有完整格式的：

• statement 格式的 binlog，最後會有 COMMIT
• row 格式的 binlog，最後會有一個 XID event

在 MySQL 5.6.2 版本以後，還引入了 binlog-checksum 引數，用來驗證 binlog 內容的正確性。對於 binlog 日誌由於磁碟原因，可能會在日誌中間出錯的情況，MySQL 可以通過校驗 checksum 的結果來發現。所以，MySQL 是有辦法驗證事務 binlog 的完整性的。 4、redo log 一般設定多大？ redo log 太小的話，會導致很快就被寫滿，然後不得不強行刷 redo log，這樣 WAL 機制的能力就發揮不出來了。 如果是幾個 TB 的磁碟的話，直接將 redo log 設定為 4 個檔案，每個檔案 1GB。 5、資料寫入後的最終落盤，是從 redo log 更新過來的還是從 buffer pool 更新過來的呢？ 實際上，redo log 並沒有記錄資料頁的完整資料，所以它並沒有能力自己去更新磁碟資料頁，也就不存在由 redo log 更新過去資料最終落盤的情況。

• 資料頁被修改以後，跟磁碟的資料頁不一致，稱為髒頁。最終資料落盤，就是把記憶體中的資料頁寫盤。這個過程與 redo log 毫無關係。
• 在崩潰恢復場景中，InnoDB 如果判斷到一個數據頁可能在崩潰恢復的時候丟失了更新，就會將它讀到記憶體，然後讓 redo log 更新記憶體內容。更新完成後，記憶體頁變成髒頁，就回到了第一種情況的狀態，刷到磁碟。

5、redo log buffer 是什麼？是先修改記憶體，還是先寫 redo log 檔案？ 在一個事務的更新過程中，日誌是要寫多次的。比如下面這個事務： Copy begin; INSERT INTO T1 VALUES ('1', '1'); INSERT INTO T2 VALUES ('1', '1'); commit; 這個事務要往兩個表中插入記錄，插入資料的過程中，生成的日誌都得先儲存起來，但又不能在還沒 commit 的時候就直接寫到 redo log 檔案裡。因此就需要 redo log buffer 出場了，它就是一塊記憶體，用來先存 redo 日誌的。也就是說，在執行第一個 insert 的時候，資料的記憶體被修改了，redo log buffer 也寫入了日誌。但是，真正把日誌寫到 redo log 檔案，是在執行 commit 語句的時候做的。 4、總結

• MySQL 主要分為 Server 層和引擎層，Server 層主要包括聯結器、查詢快取、分析器、優化器、執行器，同時還有一個日誌模組（binlog），這個日誌模組所有執行引擎都可以共用,redolog 只有 InnoDB 有。
• 引擎層是外掛式的，目前主要包括，MyISAM,InnoDB,Memory 等。
• 查詢語句的執行流程如下：許可權校驗（如果命中快取）---》查詢快取---》分析器---》優化器---》許可權校驗---》執行器---》引擎
• 更新語句執行流程如下：分析器----》許可權校驗----》執行器---》引擎---redo log(prepare 狀態---》binlog---》redo log(commit狀態)