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