MySQL 基本架構(gòu).png

mysql分為sever層和存儲(chǔ)引擎層：

• sever層包括連接器、查詢緩存、分析器、優(yōu)化器、執(zhí)行器等，涵蓋 MySQL 的大多數(shù)核心服務(wù)功能，以及所有的內(nèi)置函數(shù)（如日期、時(shí)間、數(shù)學(xué)和加密函數(shù)等），所有跨存儲(chǔ)引擎的功能都在這一層實(shí)現(xiàn)，比如存儲(chǔ)過(guò)程、觸發(fā)器、視圖等
• 存儲(chǔ)引擎層負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和提取，使用的是插件式，可支持innodb、memory、myisam等

(1)連接器

連接器負(fù)責(zé)跟客戶端建立連接、獲取權(quán)限、維持和管理連接

連接器.png

相關(guān)命令/參數(shù)

①wait_timeout:連接器保持和客戶端空閑連接時(shí)間，超時(shí)會(huì)斷開(kāi)
②show processlist:顯示用戶運(yùn)行線程

思考

①為什么推薦使用長(zhǎng)連接？

• 建立連接的過(guò)程通常比較復(fù)雜

②推薦使用長(zhǎng)連接，但如何解決長(zhǎng)連接內(nèi)存占用太大問(wèn)題？

• 定期斷開(kāi)長(zhǎng)連接
• MySQL 5.7 及以上，可以在每次執(zhí)行一個(gè)比較大的操作后，通過(guò)執(zhí)行 mysql_reset_connection來(lái)重新初始化連接資源。這個(gè)過(guò)程不需要重連和重新做權(quán)限驗(yàn)證，但是會(huì)將連接恢復(fù)到剛剛創(chuàng)建完時(shí)的狀態(tài)。

(2)查詢緩存(MySQL 8.0 版本已去掉查詢緩存)

查詢緩存.png

思考

①為什么不推薦使用查詢緩存？查詢緩存適用場(chǎng)景？如何按需使用緩存？

• 查詢緩存的失效非常頻繁，只要有對(duì)一個(gè)表的更新，這個(gè)表上所有的查詢緩存都會(huì)被清空
• 適用場(chǎng)景：靜態(tài)表，很長(zhǎng)時(shí)間才會(huì)更新一次。比如，一個(gè)系統(tǒng)配置表，那這張表上的查詢才適合使用查詢緩存
• mysql8.0以前可以按需使用緩存：select SQL_CACHE * from T where ID=10;（需要將query_cache_type設(shè)置成 DEMAND）

query_cache_type=0/OFF：關(guān)閉查詢緩存。
query_cache_type=1/ON：開(kāi)啟查詢緩存。
query_cache_type=2/ DEMAND :當(dāng)使用 SELECT SQL_CACHE會(huì)開(kāi)啟緩存

(3)分析器

詞法分析(sql中每個(gè)字符串代表什么)
語(yǔ)法分析(sql是否符合mysql語(yǔ)法)

(4)優(yōu)化器

確定使用什么索引，怎么進(jìn)行連接表等，最終確認(rèn)一個(gè)執(zhí)行方案

思考

①優(yōu)化器是怎么選擇索引的，有沒(méi)有可能選擇錯(cuò)？

• 根據(jù)掃描行數(shù)、是否排序、是否使用臨時(shí)表、是否回表等

(5)執(zhí)行器

執(zhí)行器.png

慢查詢?nèi)罩局?code>rows_examined的字段，表示這個(gè)語(yǔ)句執(zhí)行過(guò)程中掃描了多少行。這個(gè)值是在執(zhí)行器每次調(diào)用引擎獲取數(shù)據(jù)行的時(shí)候累加的。
在有些場(chǎng)景下，執(zhí)行器調(diào)用一次，在引擎內(nèi)部則掃描了多行，因此引擎掃描行數(shù)跟 rows_examined 并不是完全相同的

思考

①有索引和無(wú)索引執(zhí)行器的執(zhí)行流程？（以select * from T where ID=10為例）

• 掃描滿足的行與全表掃描再判斷的區(qū)別（這個(gè)過(guò)程是執(zhí)行器調(diào)用引擎接口執(zhí)行的）

參考：

[1]極客時(shí)間