MySQL 在整體架構上分為 Server 層和存儲引擎層。其中 Server 層，包括連接器、查詢緩存、分析器、優化器、執行器等，存儲過程、觸發器、視圖和內置函數都在這層實現。數據引擎層負責數據的存儲和提取，如 InnoDB、MyISAM、Memory 等引擎。在客戶端連接到 Server 層后，Server 會調用數據引擎提供的接口，進行數據的變更。

連接器

負責和客戶端建立連接，獲取用戶權限以及維持和管理連接。

通過show processlist來查詢連接的狀態。在用戶建立連接后，即使管理員改變連接用戶的權限，也不會影響到已連接的用戶。默認連接時長為 8 小時，超過時間后將會被斷開。

簡單說下長連接：

1. 優勢：在連接時間內，客戶端一直使用同一連接，避免多次連接的資源消耗。

2. 劣勢：在MySQL執行時，使用的內存被連接對象管理，由于長時間沒有被釋放，會導致系統內存溢出，被系統kill. 所以需要定期斷開長連接，或執行大查詢后，斷開連接。MySQL 5.7 后，可以通過mysql_rest_connection初始化連接資源，不需要重連或者做權限驗證。

查詢緩存

當接受到查詢請求時，會現在查詢緩存中查詢（key/value保存），是否執行過。沒有的話，再走正常的執行流程。

但在實際情況下，查詢緩存一般沒有必要設置。因為在查詢涉及到的表被更新時，緩存就會被清空。所以適用于靜態表。在MySQL8.0后，查詢緩存被廢除。

分析器

1. 詞法分析：如識別select，表名，列名，判斷其是否存在等。

2. 語法分析：判斷語句是否符合MySQL語法。

優化器

確定索引的使用，join表的連接順序等，選擇最優化的方案。

執行器

在具體執行語句前，會先進行權限的檢查，通過后使用數據引擎提供的接口，進行查詢。如果設置了慢查詢，會在對應日志中看到rows_examined來表示掃描的行數。在一些場景下（索引），執行器調用一次，但在數據引擎中掃描了多行，所以引擎掃描的行數和rows_examined并不完全相同。

不預先檢查權限的原因：如像觸發器等情況，需要在執行器階段才能確定權限，在優化器階段無法驗證。

MySQL 日志模塊

如前面所說，MySQL整體分為Server層和數據引擎層，而每層也對應了自己的日志文件。如果選用的是InnoDB引擎，對應的是redo log文件。Server層則對應了binlog文件。至于為什么存在了兩種日志系統，咱們往下看。

1. redo log

redo log是InnoDB特有日志，為什么要引入redo log呢，想象這樣一個場景，MySQL為了保證持久性是需要把數據寫入磁盤文件的。我們知道，在寫入磁盤時，會進行文件的 IO，查找操作，如果每次更新操作都這樣的話，整體的效率就會特別低，根本沒法使用。

既然直接寫入磁盤不行，解決方法就是先寫進內存，在系統空閑時再更新到磁盤就可以了。但光更新內存不行，假如系統出現異常宕機和重啟，內存中沒有被寫入磁盤的數據就會被丟掉，數據的一致性就出現問題了。

這時redo log就發揮了作用，在更新操作發生時，InnoDb會先寫入redo log日志（記錄了數據發生了怎么樣的改變），然后更新內存，最后在適當的時間再寫入磁盤。先寫日志，在寫磁盤的操作，就是常說到的WAL（Write-Ahead- Logging）技術。

redo log的出現，除了在效率上有了很大的改善，還保證了MySQL具有了crash-safe的能力，在發生異常情況下，不會丟失數據。

在具體實現上redo log的大小是固定的，可配置一組為 4 個文件，每個文件1GB，更新時對四個文件進行循環寫入。

write pos記錄當前寫入的位置，寫完就后移，當第寫入第4個文件的末尾時，從第0號位置重新寫入。

check point表示當前可以擦除的位置，當數據更新到磁盤時，check point就向后移動。

write pos和check point之間的位置，就是可以記錄更新操作的空間。當write pos追上check point ，不在能執行新的操作，先讓check point去寫入一些數據。

可以將innodb_flush_log_at_trx_commit設置成1，開啟redo log持久化的能力。

2. binlog

binlog則是Server層的日志，主要用于歸檔，在備份，主備同步，恢復數據時發揮作用，常見的日志格式有row, mixed, statement三種。

可以通過sync_binlog=1開啟binlog寫入磁盤。

這里對binlog和 redo進行下區分：

• 所有者不同：binlog是 Server層，所有引擎都可使用。redo log是 InnoDB特有的。

• 類型不同：binlog是邏輯日志，記錄的是語句的原始邏輯（比 statement）。redo log是物理日志，記錄某個數據頁被做了怎樣的修改。

• 數據寫入的方式不同：binog日志會一直追加，而redo log是循環寫入。

• 功能不同：binlog用于歸檔，而redo log用于保證crash-safe。

3. 兩階段提交

一條更新語句，在InnoDB引擎下的更新過程如下。在更新內存后，將寫入redolog和寫入 binlog放在一起成為一個事務最后一起寫入redo log和 binlog的過程就是常說的兩階段提交。用于保證當有意外情況發生時，數據的一致性。

這里假設下，如果不采用兩階段提交會發生什么？

• 先寫redo log后寫binlog假設在寫入redo log后，MySQL發生異常重啟，此時binlog沒有寫入。在重啟后，由于redolog已經寫入，此時數據庫的內容是沒有問題的。但此時，如果想要拿binlog進行備份或恢復，發現會少了最后一條的更新邏輯，導致數據不一致。

• 先寫binlog和redo log. binlog寫入后，MySQL異常重啟，redo log沒有寫入。此時重啟后，發現redo log沒有成功寫入，認為這個事務無效，而此時binlog卻多了一條更新語句，拿去恢復后自然數據也是不一致的。

再分析下兩階段提交的過程：

• 在寫redo log prepare階段奔潰，重啟后，發現redo log沒寫入，回滾此次事務。

• 如果在寫binlog時奔潰，重啟后，發現binlog未被寫入，回滾操作

• 如果在寫入redo log和binlog后崩潰，重啟后，發現沒提交，則進行commit。

總結

在文章開始部分，說明了MySQL的整體架構分為Server層和引擎層，并簡要說明了一條語句的執行過程。接著MySQL在5.5后選用InnoDB作為默認的引擎，就是因為比原生的MyISAM多了事務以及crash-safe的能力。

而crash-safe就是由redo log實現的。與redo log類似的日志文件還有binlog，是Server引擎的日志，用于歸檔和備份數據。

最后提到了，為了保證數據的一致性，將redo log和binlog放入相同的事務中，也就是常提到的兩階段提交操作。

End.

作者：以終為始

來源：博客園

本文為轉載分享，如侵權請聯系后臺刪除