高性能MySQL之基礎架構

原文: 高性能MySQL之基礎架構

1、背景

當你手中抓住一件東西不放時，你只能擁有一件東西，若是你肯放手，你就有機會選擇更多。與其在別人的生活裏跑龍套，不如精彩作本身。人無所舍，必無所成。跌倒了，失去了，沒關係，爬起來繼續風雨兼程，且歌且行。

爲何咱們須要先學習MYSQL的基礎架構先呢？

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

2、Mysql整體邏輯架構

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

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

2、鏈接器

當咱們要 執行 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 的優化器主要幹以下幾個重要的事情：

一、選擇最合適的索引；
二、選擇表掃仍是走索引；
三、選擇表關聯順序；
四、優化 where 子句；
五、排除管理中無用表；
六、決定 order by 和 group by 是否走索引；
七、嘗試使用 inner join 替換 outer join；
八、簡化子查詢，決定結果緩存；
九、合併試圖；

六.執行器

通過優化器知道了該怎麼作，因而就進入了執行器階段，開始執行語句。開始執行的時候，要先判斷一下你對這個表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是成本換來的，就須要你根據業務重要性來評估了。