高效能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 個數據行，col2 上掃描 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'
如果有許可權，就繼續往下執行，這時候執行器就會根據表的引擎定義，去使用這個引擎提供的介面。
這條語句在執行器的執行流程如下：
-
呼叫InnoDB引擎介面取這個表的第一行，判斷ID值是不是1，如果不是則跳過，如果是則將這行存在結果集中；
-
呼叫引擎介面取“下一行”，重複相同的判斷邏輯，直到取到這個表的最後一行。
-
執行器將上述遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給客戶端。
至此，這個語句就執行完成了。對於有索引的表，執行的邏輯也差不多。第一次呼叫的是“取滿足條件的第一行”這個介面，之後迴圈取“滿足條件的下一行”這個介面，這些介面都是引擎中已經定義好的。你會在資料庫的慢查詢日誌中看到一個rows_examined的欄位，表示這個語句執行過程中掃描了多少行。這個值就是在執行器每次呼叫引擎獲取資料行的時候累加的。
在有些場景下，執行器呼叫一次，在引擎內部則掃描了多行，因此引擎掃描行數跟rows_examined並不是完全相同的。我們後面會專門有一篇文章來講儲存引擎的內部機制，裡面會有詳細的說明。
三. 實戰鞏固
執行了這個語句 select * from T where k=1, 必然會報“不存在這個列”的錯誤： “Unknown column ‘k’ in ‘where clause’”。讓我悶想一下這是上面哪個階段報出來的呢？
答案：很明顯是分析器階段，因為詞法分析的時候會解析出查詢的表，列等等，所以此時就應該能知道表列的存在性。而且從我個人的拙見來看，如果先一步判斷出這種無法查詢的錯誤，避免後續執行，則可以避免無謂的效能開銷。而表列的資料較少，完全可以這裡判