- MySQL基礎(chǔ)架構(gòu)分析
1.1 MySQL基本架構(gòu)概述
1.2 Server層基本組件介紹(連接器靶衍，查詢緩存酪我，分析器司浪，優(yōu)化器泊业，執(zhí)行器)- 語(yǔ)句分析
2.1 查詢語(yǔ)句
2.2 更新語(yǔ)句- 總結(jié)
1.MySQL基礎(chǔ)架構(gòu)分析
1.1 MySQL基本架構(gòu)概述
MySQL主要分為Server層和存儲(chǔ)引擎層:
Server層: 主要包括連接器把沼、查詢緩存、分析器吁伺、優(yōu)化器饮睬、執(zhí)行器等，所有跨存儲(chǔ)引擎的功能都在這一層實(shí)現(xiàn)箱蝠，比如存儲(chǔ)過(guò)程续捂、觸發(fā)器、視圖宦搬，函數(shù)等牙瓢，還有一個(gè)通用的日志模塊 binglog 日志模塊。
存儲(chǔ)引擎: 主要負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取间校，采用可以替換的插件式架構(gòu)矾克，支持 InnoDB、MyISAM憔足、Memory 等多個(gè)存儲(chǔ)引擎胁附，其中 InnoDB 引擎有自有的日志模塊 redolog 模塊。現(xiàn)在最常用的存儲(chǔ)引擎是 InnoDB滓彰，它從 MySQL 5.5.5 版本開始就被當(dāng)做默認(rèn)存儲(chǔ)引擎了控妻。
簡(jiǎn)述Server層各個(gè)組件的作用:
- 連接器: 身份認(rèn)證和權(quán)限相關(guān)(登錄 MySQL 的時(shí)候)。
- 查詢緩存: 執(zhí)行查詢語(yǔ)句的時(shí)候揭绑，會(huì)先查詢緩存（MySQL 8.0 版本后移除弓候，因?yàn)檫@個(gè)功能不太實(shí)用）。
- 分析器: 沒(méi)有命中緩存的話他匪，SQL 語(yǔ)句就會(huì)經(jīng)過(guò)分析器菇存，分析器說(shuō)白了就是要先看你的 SQL 語(yǔ)句要干嘛，再檢查你的 SQL 語(yǔ)句語(yǔ)法是否正確邦蜜。
- 優(yōu)化器: 按照 MySQL 認(rèn)為最優(yōu)的方案去執(zhí)行依鸥。
- 執(zhí)行器: 執(zhí)行語(yǔ)句，然后從存儲(chǔ)引擎返回?cái)?shù)據(jù)悼沈。
1.2 Server層基本組件介紹
1.2.1 連接器
連接器主要和身份認(rèn)證和權(quán)限相關(guān)的功能相關(guān)贱迟。
主要負(fù)責(zé)用戶登錄數(shù)據(jù)庫(kù)，進(jìn)行用戶的身份認(rèn)證井辆，包括校驗(yàn)賬戶密碼关筒，權(quán)限等操作，如果用戶賬戶密碼已通過(guò)杯缺，連接器會(huì)到權(quán)限表中查詢?cè)撚脩舻乃袡?quán)限蒸播，之后在這個(gè)連接里的權(quán)限邏輯判斷都是會(huì)依賴此時(shí)讀取到的權(quán)限數(shù)據(jù)，也就是說(shuō)，后續(xù)只要這個(gè)連接不斷開袍榆，即時(shí)管理員修改了該用戶的權(quán)限胀屿，該用戶也是不受影響的。
1.2.2 查詢緩存(MySQL 8.0 版本后移除)
查詢緩存主要用來(lái)緩存我們所執(zhí)行的 SELECT 語(yǔ)句以及該語(yǔ)句的結(jié)果集包雀。
連接建立后宿崭，執(zhí)行查詢語(yǔ)句的時(shí)候，會(huì)先查詢緩存才写，MySQL 會(huì)先校驗(yàn)這個(gè) sql 是否執(zhí)行過(guò)葡兑，以 Key-Value 的形式緩存在內(nèi)存中，Key 是查詢預(yù)計(jì)赞草，Value 是結(jié)果集讹堤。如果緩存 key 被命中，就會(huì)直接返回給客戶端厨疙，如果沒(méi)有命中洲守，就會(huì)執(zhí)行后續(xù)的操作，完成后也會(huì)把結(jié)果緩存起來(lái)沾凄，方便下一次調(diào)用梗醇。當(dāng)然在真正執(zhí)行緩存查詢的時(shí)候還是會(huì)校驗(yàn)用戶的權(quán)限，是否有該表的查詢條件撒蟀。
MySQL 查詢不建議使用緩存叙谨，因?yàn)椴樵兙彺媸г趯?shí)際業(yè)務(wù)場(chǎng)景中可能會(huì)非常頻繁，假如你對(duì)一個(gè)表更新的話保屯，這個(gè)表上的所有的查詢緩存都會(huì)被清空唉俗。對(duì)于不經(jīng)常更新的數(shù)據(jù)來(lái)說(shuō)，使用緩存還是可以的配椭。
所以，一般在大多數(shù)情況下我們都是不推薦去使用查詢緩存的雹姊。
MySQL 8.0 版本后刪除了緩存的功能股缸，官方也是認(rèn)為該功能在實(shí)際的應(yīng)用場(chǎng)景比較少，所以干脆直接刪掉了吱雏。
1.2.3 分析器
MySQL 沒(méi)有命中緩存敦姻，那么就會(huì)進(jìn)入分析器，分析器主要是用來(lái)分析 SQL 語(yǔ)句是來(lái)干嘛的歧杏，分析器也會(huì)分為幾步：
第一步镰惦，詞法分析，一條 SQL 語(yǔ)句有多個(gè)字符串組成犬绒，首先要提取關(guān)鍵字旺入，比如 select，提出查詢的表，提出字段名茵瘾，提出查詢條件等等礼华。做完這些操作后，就會(huì)進(jìn)入第二步拗秘。
第二步圣絮，語(yǔ)法分析，主要就是判斷你輸入的 sql 是否正確雕旨，是否符合 MySQL 的語(yǔ)法扮匠。
1.2.4 優(yōu)化器
優(yōu)化器的作用就是它認(rèn)為的最優(yōu)的執(zhí)行方案去執(zhí)行，比如多個(gè)索引的時(shí)候該如何選擇索引凡涩，多表查詢的時(shí)候如何選擇關(guān)聯(lián)順序等棒搜。
1.2.5 執(zhí)行器
當(dāng)選擇了執(zhí)行方案后，MySQL 就準(zhǔn)備開始執(zhí)行了突照，首先執(zhí)行前會(huì)校驗(yàn)該用戶有沒(méi)有權(quán)限帮非，如果沒(méi)有權(quán)限，就會(huì)返回錯(cuò)誤信息讹蘑，如果有權(quán)限末盔，就會(huì)去調(diào)用引擎的接口，返回接口執(zhí)行的結(jié)果座慰。
2. 語(yǔ)句分析
2.1 查詢語(yǔ)句
例如：
select * from tb_student A where A.age='18' and A.name=' 張三 ';
該語(yǔ)句的執(zhí)行流程:
先檢查該語(yǔ)句是否有權(quán)限陨舱，如果沒(méi)有權(quán)限，直接返回錯(cuò)誤信息版仔，如果有權(quán)限游盲，在 MySQL8.0 版本以前，會(huì)先查詢緩存蛮粮，以這條 sql 語(yǔ)句為 key 在內(nèi)存中查詢是否有結(jié)果益缎，如果有直接緩存，如果沒(méi)有然想，執(zhí)行下一步莺奔。
通過(guò)分析器進(jìn)行詞法分析，提取 sql 語(yǔ)句的關(guān)鍵元素变泄，比如提取上面這個(gè)語(yǔ)句是查詢 select令哟，提取需要查詢的表名為 tb_student，需要查詢所有的列妨蛹，查詢條件是這個(gè)表的 id='1'屏富。然后判斷這個(gè) sql 語(yǔ)句是否有語(yǔ)法錯(cuò)誤，比如關(guān)鍵詞是否正確等等蛙卤，如果檢查沒(méi)問(wèn)題就執(zhí)行下一步狠半。
-
接下來(lái)就是優(yōu)化器進(jìn)行確定執(zhí)行方案，上面的 sql 語(yǔ)句，可以有兩種執(zhí)行方案：
a.先查詢學(xué)生表中姓名為“張三”的學(xué)生典予，然后判斷是否年齡是 18甜滨。 b.先找出學(xué)生中年齡 18 歲的學(xué)生，然后再查詢姓名為“張三”的學(xué)生瘤袖。那么優(yōu)化器根據(jù)自己的優(yōu)化算法進(jìn)行選擇執(zhí)行效率最好的一個(gè)方案（優(yōu)化器認(rèn)為衣摩，有時(shí)候不一定最好）。那么確認(rèn)了執(zhí)行計(jì)劃后就準(zhǔn)備開始執(zhí)行了捂敌。
進(jìn)行權(quán)限校驗(yàn)艾扮，如果沒(méi)有權(quán)限就會(huì)返回錯(cuò)誤信息，如果有權(quán)限就會(huì)調(diào)用數(shù)據(jù)庫(kù)引擎接口占婉，返回引擎的執(zhí)行結(jié)果泡嘴。
2.2 更新語(yǔ)句
例如：
update tb_student A set A.age='19' where A.name=' 張三 ';
其實(shí)條語(yǔ)句也基本上會(huì)沿著上一個(gè)查詢的流程走，只不過(guò)執(zhí)行更新的時(shí)候需要記錄日志逆济，MySQL 自帶的日志模塊式 binlog（歸檔日志） 酌予，所有的存儲(chǔ)引擎都可以使用，我們常用的 InnoDB 引擎還自帶了一個(gè)日志模塊 redo log（重做日志）奖慌，這個(gè)語(yǔ)句的執(zhí)行流程為:
- 先查詢到張三這一條數(shù)據(jù)抛虫，如果有緩存，也是會(huì)用到緩存简僧。
- 然后拿到查詢的語(yǔ)句建椰，把 age 改為 19，然后調(diào)用引擎 API 接口岛马，寫入這一行數(shù)據(jù)棉姐，InnoDB 引擎把數(shù)據(jù)保存在內(nèi)存中，同時(shí)記錄 redo log啦逆，此時(shí) redo log 進(jìn)入 prepare 狀態(tài)伞矩，然后告訴執(zhí)行器，執(zhí)行完成了夏志，隨時(shí)可以提交扭吁。
- 執(zhí)行器收到通知后記錄 binlog，然后調(diào)用引擎接口盲镶，提交 redo log 為提交狀態(tài)。
- 更新完成蝌诡。
使用兩個(gè)日志模塊的原因
因?yàn)樽铋_始 MySQL 并沒(méi)與 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) 溉贿，MySQL 自帶的引擎是 MyISAM，但是我們知道 redo log 是 InnoDB 引擎特有的浦旱，其他存儲(chǔ)引擎都沒(méi)有宇色，這就導(dǎo)致會(huì)沒(méi)有 crash-safe 的能力(crash-safe 的能力即使數(shù)據(jù)庫(kù)發(fā)生異常重啟，之前提交的記錄都不會(huì)丟失)，binlog 日志只能用來(lái)歸檔宣蠕。
redo log為什么使用兩階段提交的方案
反證法(總的來(lái)說(shuō)就是會(huì)有數(shù)據(jù)不一致的問(wèn)題):
- 先寫 redo log 直接提交例隆，然后寫 binlog，假設(shè)寫完 redo log 后抢蚀，機(jī)器掛了镀层，binlog 日志沒(méi)有被寫入，那么機(jī)器重啟后皿曲，這臺(tái)機(jī)器會(huì)通過(guò) redo log 恢復(fù)數(shù)據(jù)唱逢，但是這個(gè)時(shí)候 bingog 并沒(méi)有記錄該數(shù)據(jù)，后續(xù)進(jìn)行機(jī)器備份的時(shí)候屋休，就會(huì)丟失這一條數(shù)據(jù)坞古，同時(shí)主從同步也會(huì)丟失這一條數(shù)據(jù)。
- 先寫 binlog劫樟，然后寫 redo log痪枫，假設(shè)寫完了 binlog，機(jī)器異常重啟了叠艳，由于沒(méi)有 redo log奶陈，本機(jī)是無(wú)法恢復(fù)這一條記錄的，但是 binlog 又有記錄虑绵，那么和上面同樣的道理尿瞭，就會(huì)產(chǎn)生數(shù)據(jù)不一致的情況。
如果采用 redo log 兩階段提交的方式就不一樣了翅睛，寫完 binglog 后声搁，然后再提交 redo log 就會(huì)防止出現(xiàn)上述的問(wèn)題，從而保證了數(shù)據(jù)的一致性捕发。如果出現(xiàn)了假設(shè) redo log 處于預(yù)提交狀態(tài)疏旨，binglog 也已經(jīng)寫完了，這個(gè)時(shí)候發(fā)生了異常重啟會(huì)怎么樣呢扎酷？ 這個(gè)就要依賴于 MySQL 的處理機(jī)制了檐涝，MySQL 的處理過(guò)程如下：
- 判斷 redo log 是否完整，如果判斷是完整的法挨，就立即提交谁榜。
- 如果 redo log 只是預(yù)提交但不是 commit 狀態(tài)，這個(gè)時(shí)候就會(huì)去判斷 binlog 是否完整凡纳，如果完整就提交 redo log, 不完整就回滾事務(wù)窃植。
從而解決了數(shù)據(jù)一致性問(wèn)題。
3. 總結(jié)
- MySQL 主要分為 Server 層和引擎層荐糜，Server 層主要包括連接器巷怜、查詢緩存葛超、分析器、優(yōu)化器延塑、執(zhí)行器绣张，同時(shí)還有一個(gè)日志模塊（binlog），這個(gè)日志模塊所有執(zhí)行引擎都可以共用,redolog 只有 InnoDB 有关带。
- 引擎層是插件式的侥涵，目前主要包括，MyISAM,InnoDB,Memory 等豫缨。
- 查詢語(yǔ)句的執(zhí)行流程如下：權(quán)限校驗(yàn)（如果命中緩存）---》查詢緩存---》分析器---》優(yōu)化器---》權(quán)限校驗(yàn)---》執(zhí)行器---》引擎
- 更新語(yǔ)句執(zhí)行流程如下：分析器----》權(quán)限校驗(yàn)----》執(zhí)行器---》引擎---redo log(prepare 狀態(tài)---》binlog---》redo log(commit狀態(tài))
