高性能MySQL之基礎架構

一、背景

當你手中抓住一件東西不放時，你只能擁有一件東西，如果你肯放手，你就有機會選擇更多。與其在別人的生活里跑龍套，不如精彩做自己。人無所舍，必無所成。跌倒了，失去了，不要緊，爬起來繼續風雨兼程，且歌且行。

為什么我們需要先學習MYSQL的基礎架構先呢？

原因很簡單，當我們需要了解一件事物的時候，我們只有站在宏觀的層面，才能層層剝絲抽繭的去理解問題。舉個例子，我們要看一個框架的源碼，一開始就想進去研究，卻發現找不着北，原因很簡單，因為我們沒有鳥瞰全貌，我們根本不知道入口在哪里。因此我們學習MYSQL的時候也是這樣。先從高緯度理解問題，最后看到里面有哪些組件，一層層的拆解，這樣讓我們對mysql有更深入的理解。廢話不多說，我們先看總體的邏輯架構圖，如下所示。

二、Mysql總體邏輯架構

從圖中不難看出，不同的存儲引擎共用一個Server層，也就是從連接器到執行器的部分。可以看到Server層包括連接器、查詢緩存、分析器、優化器、執行器等，涵蓋MySQL的大多數核心服務功能，以及所有的內置函數（如日期、時間、數學和加密函數等），所有跨存儲引擎的功能都在這一層實現，比如觸發器、視圖等。

需要主意的是存儲引擎層負責數據的存儲和提取。其架構模式是插件式的，支持InnoDB、MyISAM、Memory等多個存儲引擎。現在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認存儲引擎。這也說明了你create table建表的時候，如果不指定引擎類型，默認使用的就是InnoDB。當然你也可以指定存儲引擎，例如create table語句中使用engine=memory, 來指定使用內存引擎創建表。接下來我們一個一個看各個組件的各自作用以及一條sql在整個架構的執行流程。

二、連接器

當我們要 執行 select * from T where ID=1；這條語句的時候，首先當然是連接器幫我們負責跟客戶端建立連接，獲取權限、位置和管理連接。連接命令如下：

mysql -h$ip -P$port -u$user -p

輸完命令之后，接下來就是經典的TCP握手了，連接器就要開始認證你的身份，這個時候用的就是你輸入的用戶名和密碼。雖然密碼也可以直接跟在-p后面寫在命令行中，但這樣可能會導致你的密碼泄露。如果你連的是生產服務器，前往不要這么做，這是生產上的禁忌。如果用戶名密碼認證通過，連接器會到權限表里面查出你擁有的權限。之后，這個連接里面的權限判斷邏輯，都將依賴於此時讀到的權限。這就意味着，一個用戶成功建立連接后，即使你用管理員賬號對這個用戶的權限做了修改，也不會影響已經存在連接的權限。修改完成后，只有再新建的連接才會使用新的權限設置。

如果你連接完成后，未來的一段時間里，你沒做任何操作，這個連接就處於空閑的狀態，你可以通過show processlist命令中看到它，如下所示：

客戶端如果太長時間沒動靜，連接器就會自動將它斷開。這個時間是由參數wait_timeout控制的，默認值是8小時。

 

如果在連接被斷開之后，客戶端再次發送請求的話，就會收到一個錯誤提醒： Lost connection to MySQL server during query。這時候如果你要繼續，就需要重連，然后再執行請求了。 

數據庫建立連接的過程通常是比較復雜的，使用中盡量減少連接的動作，也就是盡量使用長連接。因為長連接是指連接成功后，如果客戶端持續有請求，則一直使用同一個連接。短連接則是指每次執行完很少的幾次查詢就斷開連接，下次查詢再重新建立一個，這樣造成開銷很大。

但是你會發現全部使用長連接后，有些時候MySql占用的內存會飆漲的很快。這是由於MySql在執行的過程中臨時使用的內存是管理在連接對象里面的。這些資源會在連接斷開的時候才釋放。所以如果長連接累積下來，可能導致內存占用太大，被系統強行殺掉（OOM），從現象看就是MySql異常重啟了。

那么如何解決這種現象呢？主要有兩種方案

    1.定期斷開長連接。使用一段時間，或者程序里面判斷執行過一個占用內存的大查詢后，斷開連接，之后要查詢再重連。

    2.如果你使用的版本是mysql 5.7以后的版本，可以在執行一個較大的操作后，通過執行mysql_reset_connection來重新初始化連接資源。這個過程不需要重連和重新做權限驗證，但是會將連接恢復到剛剛創建完時的狀態。

 

三.查詢緩存

  連接建立完成后，就可以執行select語句去查詢了，這時候執行邏輯就走到第二步：查詢緩存。MYSQL拿到一個請求的時候，會先去緩存看有沒有這個這條語句的執行結果，之前執行過的語句以及結果會以key-value 的形式緩存在內存中，當然，key就是sql語句了，value 就是之前的執行結果。如果語句不在查詢緩存中，就會繼續后面的執行階段。執行完成后，執行結果會被存入查詢緩存中。你可以看到，如果查詢命中緩存，MySQL不需要執行后面的復雜操作，就可以直接返回結果，這個效率會很高。

但是大多數情況下，強烈不建議你去使用查詢緩存，這時候你們肯定會想，為什么不用呀，這不是挺好的呀？

原因一： cache 的訪問由一個單一的全局鎖來控制，這時候大量的查詢將被阻塞，直至鎖釋放。所以不要簡單認為設置 cache 必定會帶來性能提升。

原因二：這是因為只要有對一個表的更新，這個表上所有的查詢緩存都會被清空。這時候就會造成查詢緩存的失效非常頻繁，你費了很大勁地把結果存起來，還沒使用呢，就被一個更新全清空了。對於更新壓力大的數據庫來說，查詢緩存的命中率會非常低。除非你的業務就是有一張靜態表，很長時間才會更新一次。比如，一個系統配置表，那這張表上的查詢才適合使用查詢緩存。

mysql還是很人性化的，你以根據你的要去使用查詢緩存，你可以將參數query_cache_type設置成DEMAND，這樣對於默認的SQL語句都不使用查詢緩存。而對於你確定要使用查詢緩存的語句，可以用SQL_CACHE顯式指定，sql例子如下所示：

mysql> select SQL_CACHE * from T where ID=10；

最近我去官網看了mysql 8.0的改變，這個查詢功能整塊被刪掉了，也就是8.0以后的版本都沒有這個功能了。

 

四.分析器

如果沒有命中查詢緩存，就要開始真正執行語句了。首先，MySQL需要對SQL語句做解析，分析器先會 詞法分析 ，mysql需要識別出你這條sql語句字符串里面的字符串分別是什么，代表什么意思。

比如，mysql會根據你輸入的select這個關鍵字識別出來，這是一個查詢語句，把“T”識別成表明T，把ID識別成 列ID。接着就是進行語法分析了，根據詞法分析的結果，語法分析器會根據語法規則，判斷你輸入的這個SQL語句是否滿足MySQL語法。如果你的語法錯誤，就會報出如下錯誤：

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'elect * from t where ID=1' at line 1

一般語法錯誤會提示第一個出現錯誤的位置，所以關注的是緊接“use near”的內容。 

五.優化器

經過了分析器后，在執行之前，還需要經過優化器的處理，為什么還需優化器呢？因為優化器是在表里面有多個索引的時候，決定使用哪個索引；或者在一個語句有多表關聯（join）的時候，決定各個表的連接順序。比如你執行下面這樣的語句，這個語句是執行兩個表的join：

mysql> select * from T1 join T2 using(ID)  where T1.A=1 and T2.B=2;

這條語句既可以先從表T1里面取出A=1的記錄的ID值，再根據ID值關聯到表T2，再判斷T2里面d的值是否等於2。也可以先從表T2里面取出B=2的記錄的ID值，再根據ID值關聯到T1，再判斷T1里面A的值是否等於1。雖然最終執行的結果是一樣的，但是執行效率卻有很大的不同。再比如優化器是怎么選擇索引的，例子如下：

SELECT C FROM T WHERE  A= 'value1' AND B = 'value2';

假設 A上的掃描了 100 個數據行，B 上掃描 50個數據行，而同時進行的測試只得到了 50個數據行。

先根據A會有100個數據行，接着進行匹配找到其中的 30 個與 B 中的值匹配記錄，其中就有 70 次是失敗了。

先根據 B會有 50 個數據行，接着進行匹配找到其中的 30 個與 A中的值匹配的記錄，只有 20次是失敗的，很顯然需要的計算和磁盤 I/O 更少。

其結果是，優化器會先選擇B索引，因為這樣做開銷更小。而優化器的作用就是決定選擇使用哪一個方案。

 

因此MySQL 的優化器主要干如下幾個重要的事情：

1、選擇最合適的索引；
2、選擇表掃還是走索引；
3、選擇表關聯順序；
4、優化 where 子句；
5、排除管理中無用表；
6、決定 order by 和 group by 是否走索引；
7、嘗試使用 inner join 替換 outer join；
8、簡化子查詢，決定結果緩存；
9、合並試圖；

六.執行器

經過優化器知道了該怎么做，於是就進入了執行器階段，開始執行語句。開始執行的時候，要先判斷一下你對這個表T有沒有執行查詢的權限，如果沒有，就會返回沒有權限的錯誤，如下所示。

select * from T where ID=1;

ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

如果有權限，就繼續往下執行，這時候執行器就會根據表的引擎定義，去使用這個引擎提供的接口。

這條語句在執行器的執行流程如下：

1. 調用InnoDB引擎接口取這個表的第一行，判斷ID值是不是1，如果不是則跳過，如果是則將這行存在結果集中；

2. 調用引擎接口取“下一行”，重復相同的判斷邏輯，直到取到這個表的最后一行。

3. 執行器將上述遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給客戶端。

至此，這個語句就執行完成了。對於有索引的表，執行的邏輯也差不多。第一次調用的是“取滿足條件的第一行”這個接口，之后循環取“滿足條件的下一行”這個接口，這些接口都是引擎中已經定義好的。你會在數據庫的慢查詢日志中看到一個rows_examined的字段，表示這個語句執行過程中掃描了多少行。這個值就是在執行器每次調用引擎獲取數據行的時候累加的。

在有些場景下，執行器調用一次，在引擎內部則掃描了多行，因此引擎掃描行數跟rows_examined並不是完全相同的。我們后面會專門有一篇文章來講存儲引擎的內部機制，里面會有詳細的說明。

 

七.日志模塊 

到了架構圖最后一部分了日志模塊了，這里與上面的查詢流程中不一樣的是，如果涉及更新流程還要涉及兩個重要的日志模塊，分別是重做日志（redo log）、歸檔日志（binlog）。

我們首先來看redo log，redo log就像古代酒店里面的一塊粉板，用來記錄客人的賒賬記錄，如果賒賬的人不多，那么他可以把顧客名和賬目寫在板上。但如果賒賬的人多了，粉板總會有記不下的時候，這個時候掌櫃一定還有一個專門記錄賒賬的賬本。這個賬本相當於我們的磁盤，如果生意很火爆的時候，如果我們通過賬本來操作賒賬和還賬的話，肯定需要通過密密麻麻的幾十頁來找到那個名字，再慢慢計算，寫入賬本。這明顯是不高效率的，特別是生意火爆的時候，效率特別慢。所以如果我們現在粉板上先記錄一下，等粉板寫滿了，或者打烊的時候再進行賬本數據與粉板的數據進行校對，這樣明顯更加能提升效率。

同樣，在MySQL里也有這個問題，如果每一次的更新操作都需要寫進磁盤，然后磁盤也要找到對應的那條記錄，然后再更新，整個過程IO成本、查找成本都很高。為了解決這個問題，MySQL的設計者就用了類似酒店掌櫃粉板的思路來提升更新效率。而粉板和賬本配合的整個過程，其實就是MySQL里經常說到的WAL技術，WAL的全稱是Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤，也就是先寫粉板，等不忙的時候再寫賬本。

因此，當有一條記錄需要更新的時候，InnoDB引擎就會先把記錄寫到redo log（粉板）里面，並更新內存，這個時候更新就算完成了。同時，InnoDB引擎會在適當的時候，將這個操作記錄更新到磁盤里面，而這個更新往往是在系統比較空閑的時候做，這就像打烊以后掌櫃做的事。如果今天賒賬的不多，掌櫃可以等打烊后再整理。但如果某天賒賬的特別多，粉板寫滿了，又怎么辦呢？這個時候掌櫃只好放下手中的活兒，把粉板中的一部分賒賬記錄更新到賬本中，然后把這些記錄從粉板上擦掉，為記新賬騰出空間。

InnoDB的redo log是固定大小的，比如可以配置為一組4個文件，每個文件的大小是1GB，那么這塊“粉板”總共就可以記錄4GB的操作。從頭開始寫，寫到末尾就又回到開頭循環寫，如下面這個圖所示。

write pos是當前記錄的指針，一邊寫一邊后移，寫到第3號文件末尾后就回到0號文件開頭。checkpoint是當前要擦除的位置，也是往后推移並且循環的，擦除記錄前要把記錄更新到數據文件。

write pos和checkpoint之間是用來記錄新的操作，即“粉板”上還空着的部分。如果write pos追上checkpoint，表示“粉板”滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint推進一下。有了redo log，InnoDB就可以保證即使數據庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。要理解crash-safe這個概念，可以想想我們前面賒賬記錄的例子。只要賒賬記錄記在了粉板上或寫在了賬本上，之后即使掌櫃忘記了，比如突然停業幾天，恢復生意后依然可以通過賬本和粉板上的數據明確賒賬賬目。

 

接下來講解binlog，我們可以從前面的架構圖看到MySql整體分為兩塊，一塊是Server層，它主要做的是MySQL功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜。上面我們聊到的粉板redo log是InnoDB引擎特有的日志，而Server層也有自己的日志，稱為binlog（歸檔日志）。這時候我們是不是又一個疑問，為什么還需要binlong 這個日志呢？

這是因為最開始MySQL里並沒有InnoDB引擎。MySQL自帶的引擎是MyISAM，但是MyISAM沒有crash-safe的能力，binlog日志只能用於歸檔。而InnoDB是另一個公司以插件形式引入MySQL的，既然只依靠binlog是沒有crash-safe能力的，所以InnoDB使用另外一套日志系統——也就是redo log來實現crash-safe能力。

這兩種日志有以下三點不同。

1. redo log存在於InnoDB；binlog是由Server層實現的，因此所有引擎都可以使用。

2. redo log是物理日志，記錄的是“在某個數據頁上做了什么修改”；binlog是邏輯日志，記錄的是這個語句的原始邏輯，比如“給ID=2這一行的c字段加1 ”。

3. redo log是循環寫的，空間固定會用完；binlog是可以追加寫入的。“追加寫”是指binlog文件寫到一定大小后會切換到下一個，並不會覆蓋以前的日志。

 接下來，通過一條更新語句來講解InnoDB引擎和執行器內部執行更新的流程。例子如下：

update T set A=A+1 where ID=1;

流程圖如下所示：

可以看到執行器和InnoDB引擎在執行這個簡單的update語句時的內部流程，步驟如下

1. 執行器先找引擎取ID=1這一行。ID是主鍵，引擎直接用樹搜索找到這一行。如果ID=1這一行所在的數據頁本來就在內存中，就直接返回給執行器；否則，需要先從磁盤讀入內存，然后再返回。

2. 執行器拿到引擎給的行數據，把這個值加上1，比如原來是N，現在就是N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。

3. 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到redo log里面，此時redo log處於prepare狀態。然后告知執行器執行完成了，隨時可以提交事務。

4. 執行器生成這個操作的binlog，並把binlog寫入磁盤。

5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的redo log改成提交（commit）狀態，更新完成。

 

接下來就是進行兩階段提交了，為什么為什么必須有“兩階段提交”呢？

這是為了讓兩份日志之間的邏輯一致。要說明這個問題，這個問題說起：怎樣讓數據庫恢復到半個月內任意一秒的狀態？

前面我們說過了，binlog會記錄所有的邏輯操作，並且是采用“追加寫”的形式。如果你的DBA承諾說半個月內可以恢復，那么備份系統中一定會保存最近半個月的所有binlog，同時系統會定期做整庫備份。這里的“定期”取決於系統的重要性，可以是一天一備，也可以是一周一備。

當需要恢復到指定的某一秒時，比如某天下午兩點發現中午十二點有一次誤刪表，需要找回數據，那你可以這么做：

• 首先，找到最近的一次全量備份，如果你運氣好，可能就是昨天晚上的一個備份，從這個備份恢復到臨時庫；
• 然后，從備份的時間點開始，將備份的binlog依次取出來，重放到中午誤刪表之前的那個時刻。

這樣你的臨時庫就跟誤刪之前的線上庫一樣了，然后你可以把表數據從臨時庫取出來，按需要恢復到線上庫去。

好了，說完了數據恢復過程，我們回來說說，為什么日志需要“兩階段提交”。這里不妨用反證法來進行解釋。

由於redo log和binlog是兩個獨立的邏輯，如果不用兩階段提交，要么就是先寫完redo log再寫binlog，或者采用反過來的順序。我們看看這兩種方式會有什么問題。

仍然用前面的update語句來做例子。假設當前ID=A的行，字段A的值是0，再假設執行update語句過程中在寫完第一個日志后，第二個日志還沒有寫完期間發生了crash，會出現什么情況呢？

1. 先寫redo log后寫binlog。假設在redo log寫完，binlog還沒有寫完的時候，MySQL進程異常重啟。由於我們前面說過的，redo log寫完之后，系統即使崩潰，仍然能夠把數據恢復回來，所以恢復后這一行A的值是1。
   但是由於binlog沒寫完就crash了，這時候binlog里面就沒有記錄這個語句。因此，之后備份日志的時候，存起來的binlog里面就沒有這條語句。
   然后你會發現，如果需要用這個binlog來恢復臨時庫的話，由於這個語句的binlog丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行A的值就是0，與原庫的值不同。

2. 先寫binlog后寫redo log。如果在binlog寫完之后crash，由於redo log還沒寫，崩潰恢復以后這個事務無效，所以這一行A的值是0。但是binlog里面已經記錄了“把A從0改成1”這個日志。所以，在之后用binlog來恢復的時候就多了一個事務出來，恢復出來的這一行A的值就是1，與原庫的值不同。

可以看到，如果不使用“兩階段提交”，那么數據庫的狀態就有可能和用它的日志恢復出來的庫的狀態不一致。

你可能會說，這個概率是不是很低，平時也沒有什么動不動就需要恢復臨時庫的場景呀？

其實不是的，不只是誤操作后需要用這個過程來恢復數據。當你需要擴容的時候，也就是需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用binlog來實現的，這個“不一致”就會導致你的線上出現主從數據庫不一致的情況。

簡單說，redo log和binlog都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。

 

總的來說redo log用於保證crash-safe能力。innodb_flush_log_at_trx_commit這個參數設置成1的時候，表示每次事務的redo log都直接持久化到磁盤。這個參數我建議你設置成1，這樣可以保證MySQL異常重啟之后數據不丟失。

sync_binlog這個參數設置成1的時候，表示每次事務的binlog都持久化到磁盤。這個參數我也建議你設置成1，這樣可以保證MySQL異常重啟之后binlog不丟失。兩階段提交是跨系統維持數據邏輯一致性時常用的一個方案。

三. 實戰鞏固

1.執行了這個語句 select * from T where k=1, 必然會報“不存在這個列”的錯誤： “Unknown column ‘k’ in ‘where clause’”。讓我悶想一下這是上面哪個階段報出來的呢？

答案：很明顯是分析器階段，因為詞法分析的時候會解析出查詢的表，列等等，所以此時就應該能知道表列的存在性。而且從我個人的拙見來看，如果先一步判斷出這種無法查詢的錯誤，避免后續執行，則可以避免無謂的性能開銷。而表列的數據較少，完全可以這里判斷。

 

2.我們知道定期全量備份的周期“取決於系統重要性，有的是一天一備，有的是一周一備”。那么在什么場景下，一天一備會比一周一備更有優勢呢？或者說，它影響了這個數據庫系統的哪個指標？

在一天一備的模式里，最壞情況下需要應用一天的binlog，好處是“最長恢復時間”更短。比如，你每天0點做一次全量備份，而要恢復出一個到昨天晚上23點的備份。

一周一備最壞情況就要應用一周的binlog了。系統的對應指標就是恢復目標時間（RTO）。當然這個是有成本的，因為更頻繁全量備份需要消耗更多存儲空間，所以這個RTO是成本換來的，就需要你根據業務重要性來評估了。