本篇文章將通過一條 SQL 的執行程序來介紹 MySQL 的基礎架構,
首先有一個 user_info 表,表里有一個 id 欄位,執行下面這條查詢陳述句:
select * from user_info where id = 1;
回傳結果為:
+----+----------+----------+--------+------+---------------------+---------------------+
| id | username | password | openid | role | create_time | update_time |
+----+----------+----------+--------+------+---------------------+---------------------+
| 1 | 武培軒 | 123 | 1 | 1 | 2019-08-29 00:29:08 | 2019-08-29 00:29:08 |
+----+----------+----------+--------+------+---------------------+---------------------+
下面給出 MySQL 的基本架構示意圖,可以看出 SQL 陳述句在 MySQL 的各個模塊中的執行程序,
MySQL 基本架構

大體上,MySQL 分為 Server 層和存盤引擎層兩部分,
Server 層包括連接器、查詢快取、分析器、執行器等,以及所有的內置函式(如日期、時間、數學和加密函式等)和跨存盤引擎的功能(如存盤程序、觸發器、視圖),
存盤引擎層負責資料的存盤和提取,支持 InnoDB、MyISAM、Memory 等多個存盤引擎,MySQL 5.5.5 版本后默認存盤存盤引擎是 InnoDB,
連接器(Connector)
在查詢 SQL 陳述句前,肯定要先建立與 MySQL 的連接,這就是由連接器來完成的,連接器負責跟客戶端建立連接、獲取權限、維持和管理連接,連接命令為:
mysql -h$ip -P$port -u$user -p
輸入密碼,驗證通過后,連接器會到權限表里面查出你擁有的權限,之后這個連接里面的權限判斷邏輯,都將依賴于此時讀到的權限,一個用戶成功建立連接后,即使管理員對這個用戶的權限做了修改,也不會影響已經存在連接的權限,修改完后,只有再新建的連接才會使用新的權限設定,
連接完成后,如果你沒有后續的動作,這個連接就處于空閑狀態,你可以在 show processlist 命令中看到它,結果如下:
+----+------+----------------+------------------+---------+------+----------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+----------------+------------------+---------+------+----------+------------------+
| 3 | root | localhost:2790 | NULL | Sleep | 5878 | | NULL |
| 4 | root | localhost:2791 | springcloud_sell | Sleep | 5838 | | NULL |
| 7 | root | localhost:2900 | springcloud_sell | Sleep | 5838 | | NULL |
| 10 | root | localhost:3627 | springcloud_sell | Query | 0 | starting | show processlist |
+----+------+----------------+------------------+---------+------+----------+------------------+
客戶端如果太長時間沒動靜,連接器就會自動將它斷開;這個時間是由引數 wait_timeout 控制的,默認值是8小時,如果在連接被斷開之后,客戶端再次發送請求的話,就會收到一個錯誤提醒:Lost connection to MySQL server during query,
長連接和短連接
- 資料庫里面,長連接是指連接成功后,如果客戶端持續有請求,則一直使用同一個連接,
- 短連接則是指每次執行完很少的幾次查詢就斷開連接,下次查詢再重新建立一個,
建立連接的程序通常是比較復雜的,建議在使用中要盡量減少建立連接的動作,盡量使用長連接,但是全部使用長連接后,有時候 MySQL 占用記憶體漲得特別快,這是因為 MySQL 在執行程序中臨時使用的記憶體是管理在連接物件里面的,這些資源會在連接斷
開的時候才釋放,所以如果長連接累積下來,可能導致記憶體占用太大,被系統強行殺掉(OOM),從現象看就是 MySQL 例外重啟了,
怎么解決這個問題呢?可以考慮以下兩種方案:
- 定期斷開長連接,使用一段時間,或者程式里面判斷執行過一個占用記憶體的大查詢后,斷開連接,之后要查詢再重連,
- MySQL 5.7 以上版本,可以在每次執行一個比較大的操作后,通過執行 mysql_reset_connection 來重新初始化連接資源,這個程序不需要重連和重新做權限驗證,但是會將連接恢復到剛剛創建完時的狀態,
查詢快取(Query Cache)
在建立連接后,就開始執行 select 陳述句了,執行前首先會查詢快取,
MySQL 拿到查詢請求后,會先查詢快取,看是不是執行過這條陳述句,執行過的陳述句及其結果會以 key-value 對的形式保存在一定的記憶體區域中,key 是查詢的陳述句,value 是查詢的結果,如果你的查詢能夠直接在這個快取中找到 key,那么這個
value 就會被直接回傳給客戶端,
如果陳述句不在查詢快取中,就會繼續后面的執行階段,執行完成后,執行結果會被存入查詢快取中,如果查詢命中快取,MySQL 不需要執行后面的復雜操作,就可以直接回傳結果,會提升效率,
但是查詢快取的失效非常頻繁,只要有對一個表的更新,這個表上所有的查詢快取都會被清空,對于更新壓力大的資料庫來說,查詢快取的命中率會非常低,如果業務中需要有一張靜態表,很長時間才會更新一次,比如,一個系統配置表,那這張表上的查詢才適合使用查詢快取,MySQL 提供了這種按需使用的方式,可以將引數 query_cache_type 設定成 DEMAND,對于默認的 SQL 陳述句都將不使用查詢快取,而對于你確定要使用查詢快取的陳述句,可以用 SQL_CACHE 顯式指定,如下:
mysql> select SQL_CACHE * from user_info where id = 1;
MySQL 8.0 版本將查詢快取的功能洗掉了,
分析器(Analyzer)
如果查詢快取未命中,就要開始執行陳述句了,首先,MySQL 需要對 SQL 陳述句進行決議,
分析器先會做詞法分析,SQL 陳述句是由多個字串和空格組成的,MySQL 需要識別出里面的字串分別是什么,代表什么,MySQL 從你輸入的 select 這個關鍵字識別出來,這是查詢陳述句,它也要把字串 user_info 識別成表名,把字串 id 識別成列名,之后就要做語法分析,根據詞法分析的結果,語法分析器會根據語法規則,判斷輸入的 SQL 陳述句是否滿足 MySQL 語法,
如果你 SQL 陳述句不對,就會收到 You have an error in your SQL syntax 的錯誤提醒,比如下面這個陳述句 from 寫成了 form,
mysql> select * form user_info where id = 1;
1064 - 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 'form user_info where id = 1' at line 1
一般語法錯誤會提示第一個出現錯誤的位置,所以要關注的是緊接 use near 的內容,
優化器(Optimizer)
經過分析器的詞法分析和語法分析后,還要經過優化器的處理,
優化器是在表里面有多個索引的時候,決定使用哪個索引;或者在一個陳述句有多表關聯(join)的時候,決定各個表的連接順序,比如你執行下面這樣的陳述句,這個陳述句是執行兩個表的 join:
mysql> SELECT * FROM order_master JOIN order_detail USING (order_id) WHERE order_master.pay_status = 0 AND order_detail.detail_id = 1558963262141624521;
既可以先從表 order_master 里面取出 pay_status = 0 的記錄的 order_id 值,再根據 order_id 值關聯到表 order_detail,再判斷 order_detail 里面 detail_id 的值是否等于 1558963262141624521,
也可以先從表 order_detail 里面取出 detail_id = 1558963262141624521 的記錄的 order_id 值,再根據 order_id 值關聯到 order_master,再判斷 order_master 里面 pay_status 的值是否等于 0,
這兩種執行方法的邏輯結果是一樣的,但是執行的效率會有不同,而優化器的作用就是決定選擇使用哪一個方案,優化器階段完成后,這個陳述句的執行方案就確定下來了,然后進入執行器階段,
執行器(Actuator)
MySQL 通過分析器知道了要做什么,通過優化器知道了該怎么做,于是就進入了執行器階段,開始執行陳述句,
開始執行的時候,要先判斷一下你對這個表 user_info 有沒有執行查詢的權限,如果沒有,就會回傳沒有權限的錯誤,如下所示 (如果命中查詢快取,會在查詢快取回傳結果的時候,做權限驗證,查詢也會在優化器之前呼叫 precheck 驗證權限),
mysql> select * from user_info where id = 1;
ERROR 1142 (42000): SELECT command denied to user 'wupx'@'localhost' for table 'user_info'
如果有權限,就打開表繼續執行,打開表的時候,執行器就會根據表的引擎定義,去使用這個引擎提供的介面,比如我們這個例子中的表 user_info 中,id 欄位沒有索引,那么執行器的執行流程是這樣的:
- 呼叫 InnoDB 引擎介面取這個表的第一行,判斷 id 值是不是 1,如果不是則跳過,如果是則將這行存在結果集中;
- 呼叫引擎介面取下一行,重復相同的判斷邏輯,直到取到這個表的最后一行,
- 執行器將上述遍歷程序中所有滿足條件的行組成的記錄集作為結果集回傳給客戶端,
對于有索引的表,第一次呼叫的是取滿足條件的第一行這個介面,之后回圈取滿足條件的下一行這個介面,
資料庫的慢查詢日志中有 rows_examined 欄位,表示這個陳述句執行程序中掃描了多少行,這個值就是在執行器每次呼叫引擎獲取資料行的時候累加的,在有些場景下,執行器呼叫一次,在引擎內部則掃描了多行,因此引擎掃描行數跟 rows_examined 并不是完全相同的,
總結
主要通過對一個 SQL 陳述句完整執行程序進行講解,介紹 MySQL 的邏輯架構,MySQL 主要包括連接器、查詢快取、分析器、優化器、執行器這幾個模塊,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/236427.html
標籤:其他
上一篇:Mysql 常見資料型別及約束
下一篇:安裝/洗掉MySQL資料庫
