MySQL邏輯架構
server 層
聯結器
聯結器負責跟客戶端建立連線
、獲取許可權
、維持連線
、管理連線
。
mysql -h$ip -P$port -u$user -p
輸完命令之後,需要在互動對話裡面輸入密碼。雖然密碼也可以直接跟在-p
後面寫在命令列中,但這樣可能會導致密碼洩露。如果連的是生產伺服器,強烈建議不要這麼做。
- 如果使用者名稱或密碼不對,會收到一個
Access denied for user
的錯誤,然後客戶端程式結束執行
。 - 如果使用者名稱密碼認證通過,聯結器會到許可權表裡面查出擁有的許可權。之後這個連線裡面的許可權判斷邏輯,都將依賴於此時讀到的許可權。
一個使用者成功建立連線後,即使用管理員賬號對這個使用者的許可權做了修改,也不會影響已經存在連線的許可權。修改完成後,只有再新建的連線才會使用新的許可權設定
。
連線完成後,如果沒有後續的動作,這個連線就處於空閒狀態,可以在show processlist
命令中看到。Command
列顯示為Sleep
的這一行,表示現在系統裡面有一個空閒連線。
mysql> show processlist; +----+------+-----------+------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------+------+---------+------+----------+------------------+ | 1 | root | localhost | test | Sleep | 20 | | NULL | +----+------+-----------+------+---------+------+----------+------------------+ | 2 | root | localhost | test | Query | 0 | starting | show processlist | +----+------+-----------+------+---------+------+----------+------------------+ 2 row in set (0.00 sec)
客戶端太長時間沒動靜,聯結器就會自動將它斷開
。時間是由引數wait_timeout
控制的,預設值是8小時
。
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.00 sec)
wait_timeout
和interactive_timeout
儘量設定成相同
。值的話取決於業務。如果是成熟的開發(比如公司內部團隊),可以設定小些,分鐘級別
就行。
如果在連線被斷開之後,客戶端再次傳送請求的話,就會收到一個錯誤提醒:Lost connection to MySQL server during query
。這時候如果要繼續,就需要重連,然後再執行請求了。
資料庫裡面,
長連線
是指連線成功後,如果客戶端持續有請求,則一直使用同一個連線。短連線
則是指每次執行完很少的幾次查詢就斷開連線,下次查詢再重新建立一個。
全部使用長連線後,有些時候 MySQL佔用記憶體
漲得特別快,這是因為 MySQL 在執行過程中臨時使用的記憶體是管理在連線物件裡面的
。這些資源會在連線斷開的時候才釋放
。所以如果長連線累積下來,可能導致記憶體佔用太大,被系統強行殺掉(OOM),從現象看就是 MySQL 異常重啟了。
解決長連線
- 定期斷開長連線。使用一段時間,或者程式裡面判斷執行過一個佔用記憶體的大查詢後,斷開連線,之後要查詢再重連。
- 如果用的是
MySQL 5.7 或更新版本
,可以在每次執行一個比較大的操作後,通過執行mysql_reset_connection
來重新初始化連線資源。這個過程不需要重連和重新做許可權驗證,但是會將連線恢復到剛剛建立完時的狀態。
表字段許可權
建立了一個沒有select
許可權的使用者,執行select * from T where k=1
,報錯select command denied
,並沒有報錯unknown column
。這個是一個安全方面
的考慮。一個使用者沒有檢視這個表的許可權,沒許可權的意思還包含了:沒許可權知道欄位是否存在
。
查詢快取
MySQL 拿到一個查詢請求後,會先到查詢快取看看,之前是不是執行過這條語句。之前執行過的語句及其結果可能會以key-value對
的形式,被直接快取在記憶體中
。key
是查詢的語句,value
是查詢的結果。如果查詢能夠直接在這個快取中找到 key
,那麼這個value
就會被直接返回給客戶端。
如果語句不在查詢快取中,就會繼續後面的執行階段。執行完成後,執行結果會被存入查詢快取中。
查詢快取的失效非常頻繁,只要有對一個表的更新
,這個表上所有的查詢快取都會被清空
。因此很可能費勁地把結果存起來,還沒使用就被一個更新全清空了。對於更新壓力大的資料庫來說,查詢快取的命中率會非常低。除非業務就是有一張靜態表,很長時間才會更新一次。比如,一個系統配置表,那這張表上的查詢才適合使用查詢快取。
可以將引數query_cache_type
設定成DEMAND
,這樣對於預設的 SQL 語句都不使用查詢快取。而對於確定要使用查詢快取的語句,可以用SQL_CACHE
顯式指定。
mysql> select SQL_CACHE * from T where ID=10;
MySQL 8.0
版本直接將查詢快取的整塊功能刪掉了。
分析器
如果沒有命中查詢快取,就要開始執行語句了。
分析器先會做詞法分析
。輸入的是由多個字串和空格組成的一條 SQL 語句,MySQL 需要識別出裡面的字串分別是什麼,代表什麼。
MySQL 從輸入的select
這個關鍵字識別出來,這是一個查詢語句。它也要把字串T
識別成表名T
,把字串ID
識別成列ID
。
做完了這些識別以後,要做語法分析
。語法分析器會根據語法規則,判斷輸入的 SQL 語句是否滿足MySQL語法
。
語句不對,就會收到You have an error in your SQL syntax
的錯誤提醒。
mysql> elect * from t where ID=1;
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
經過了分析器,MySQL 就知道要做什麼了。
優化器
優化器是在表裡面有多個索引的時候,決定使用哪個索引。或者在一個語句有多表關聯(join)的時候,決定各個表的連線順序。
mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;
- 既可以先從表 t1 裡面取出 c=10 的記錄的 ID 值,再根據 ID 值關聯到表 t2,再判斷 t2 裡面 d 的值是否等於 20。
- 也可以先從表 t2 裡面取出 d=20 的記錄的 ID 值,再根據 ID 值關聯到 t1,再判斷 t1 裡面 c 的值是否等於 10。
兩種執行方法的邏輯結果是一樣的
,但執行的效率會有不同
,而優化器的作用就是決定選擇使用哪一個方案。
優化器階段完成後,語句的執行方案就確定下來了。
執行器
開始執行的時候,要先判斷一下對這個表T
有沒有執行查詢的許可權,如果沒有,就會返回沒有許可權的錯誤。(在工程實現上,如果命中查詢快取,會在查詢快取放回結果的時候,做許可權驗證。查詢也會在優化器之前呼叫precheck
驗證許可權)。
mysql> select * from T where ID=10;
ERROR 1142 (42000):SELECT command denied to user 'b'@'localhost' for table 'T'
如果有許可權,就開啟表繼續執行。開啟表的時候,執行器就會根據表的引擎定義,去使用這個引擎提供的介面。
表T
中,ID欄位沒有索引
,執行器的執行流程:
- 呼叫 InnoDB 引擎介面取這個表的第一行,判斷 ID 值是不是 10,如果不是則跳過,如果是則將這行存在結果集中;
- 呼叫引擎介面取
下一行
,重複相同的判斷邏輯,直到取到這個表的最後一行
執行器將上述遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給客戶端。
對於有索引的表,執行的邏輯也差不多。第一次呼叫的是取滿足條件的第一行
這個介面,之後迴圈取滿足條件的下一行
這個介面,這些介面都是引擎中已經定義好的。
慢查詢日誌的rows_examined
欄位,表示這個語句執行過程中掃描了多少行。這個值就是在執行器每次呼叫引擎獲取資料行
的時候累加
的。
引擎掃描行數
跟rows_examined
並不是完全相同的。
儲存引擎層
儲存引擎負責 MySQL 中資料的儲存和讀取。伺服器通過 API 與儲存引擎進行通訊。這些介面遮蔽了不同儲存引擎之間的差異,使得這些差異對上層的查詢過程透明。儲存引擎不會解析 SQL(InnoDb例外,它會解析外來鍵定義,因為MySQL伺服器本身沒有實現該功能。)
,不同儲存引擎之間也不會相互通訊,而只是簡單地響應上層伺服器的請求。