一 MySQL 基礎(chǔ)架構(gòu)分析
1.1 MySQL 基本架構(gòu)概覽
下圖是 MySQL 的一個簡要架構(gòu)圖，從下圖你可以很清晰的看到用戶的 SQL 語句在 MySQL 內(nèi)部是如何執(zhí)行的。
先簡單介紹一下下圖涉及的一些組件的基本作用幫助大家理解這幅圖糠雨，在 1.2 節(jié)中會詳細介紹到這些組件的作用。
- 連接器： 身份認證和權(quán)限相關(guān)(登錄 MySQL 的時候)咆繁。
- 查詢緩存: 執(zhí)行查詢語句的時候，會先查詢緩存（MySQL 8.0 版本后移除顶籽，因為這個功能不太實用）玩般。
- 分析器: 沒有命中緩存的話，SQL 語句就會經(jīng)過分析器礼饱，分析器說白了就是要先看你的 SQL 語句要干嘛坏为，再檢查你的 SQL 語句語法是否正確。
- 優(yōu)化器： 按照 MySQL 認為最優(yōu)的方案去執(zhí)行镊绪。
- 執(zhí)行器: 執(zhí)行語句久脯，然后從存儲引擎返回數(shù)據(jù)。
簡單來說 MySQL 主要分為 Server 層和存儲引擎層：
- Server 層：主要包括連接器镰吆、查詢緩存帘撰、分析器、優(yōu)化器万皿、執(zhí)行器等摧找，所有跨存儲引擎的功能都在這一層實現(xiàn)，比如存儲過程牢硅、觸發(fā)器蹬耘、視圖，函數(shù)等减余，還有一個通用的日志模塊 binglog 日志模塊综苔。
- 存儲引擎： 主要負責(zé)數(shù)據(jù)的存儲和讀取，采用可以替換的插件式架構(gòu)，支持 InnoDB如筛、MyISAM堡牡、Memory 等多個存儲引擎，其中 InnoDB 引擎有自有的日志模塊 redolog 模塊杨刨。現(xiàn)在最常用的存儲引擎是 InnoDB晤柄，它從 MySQL 5.5.5 版本開始就被當(dāng)做默認存儲引擎了。
1.2 Server 層基本組件介紹
1) 連接器
連接器主要和身份認證和權(quán)限相關(guān)的功能相關(guān)妖胀，就好比一個級別很高的門衛(wèi)一樣芥颈。
主要負責(zé)用戶登錄數(shù)據(jù)庫，進行用戶的身份認證赚抡，包括校驗賬戶密碼爬坑，權(quán)限等操作，如果用戶賬戶密碼已通過涂臣，連接器會到權(quán)限表中查詢該用戶的所有權(quán)限妇垢，之后在這個連接里的權(quán)限邏輯判斷都是會依賴此時讀取到的權(quán)限數(shù)據(jù)，也就是說肉康，后續(xù)只要這個連接不斷開，即時管理員修改了該用戶的權(quán)限灼舍，該用戶也是不受影響的吼和。
2) 查詢緩存(MySQL 8.0 版本后移除)
查詢緩存主要用來緩存我們所執(zhí)行的 SELECT 語句以及該語句的結(jié)果集。
連接建立后骑素，執(zhí)行查詢語句的時候炫乓，會先查詢緩存，MySQL 會先校驗這個 sql 是否執(zhí)行過献丑，以 Key-Value 的形式緩存在內(nèi)存中末捣，Key 是查詢預(yù)計，Value 是結(jié)果集创橄。如果緩存 key 被命中箩做，就會直接返回給客戶端，如果沒有命中妥畏，就會執(zhí)行后續(xù)的操作邦邦，完成后也會把結(jié)果緩存起來，方便下一次調(diào)用醉蚁。當(dāng)然在真正執(zhí)行緩存查詢的時候還是會校驗用戶的權(quán)限燃辖，是否有該表的查詢條件。
MySQL 查詢不建議使用緩存网棍，因為查詢緩存失效在實際業(yè)務(wù)場景中可能會非常頻繁黔龟，假如你對一個表更新的話，這個表上的所有的查詢緩存都會被清空。對于不經(jīng)常更新的數(shù)據(jù)來說氏身，使用緩存還是可以的巍棱。
所以，一般在大多數(shù)情況下我們都是不推薦去使用查詢緩存的观谦。
MySQL 8.0 版本后刪除了緩存的功能拉盾，官方也是認為該功能在實際的應(yīng)用場景比較少，所以干脆直接刪掉了豁状。
3) 分析器
MySQL 沒有命中緩存捉偏，那么就會進入分析器，分析器主要是用來分析 SQL 語句是來干嘛的泻红，分析器也會分為幾步：
第一步夭禽，詞法分析，一條 SQL 語句有多個字符串組成谊路，首先要提取關(guān)鍵字讹躯，比如 select，提出查詢的表缠劝，提出字段名潮梯，提出查詢條件等等。做完這些操作后惨恭，就會進入第二步秉馏。
第二步，語法分析脱羡，主要就是判斷你輸入的 sql 是否正確萝究，是否符合 MySQL 的語法。
完成這 2 步之后锉罐，MySQL 就準(zhǔn)備開始執(zhí)行了帆竹，但是如何執(zhí)行，怎么執(zhí)行是最好的結(jié)果呢脓规？這個時候就需要優(yōu)化器上場了栽连。
4) 優(yōu)化器
優(yōu)化器的作用就是它認為的最優(yōu)的執(zhí)行方案去執(zhí)行（有時候可能也不是最優(yōu)，這篇文章涉及對這部分知識的深入講解）侨舆，比如多個索引的時候該如何選擇索引升酣，多表查詢的時候如何選擇關(guān)聯(lián)順序等。
可以說态罪，經(jīng)過了優(yōu)化器之后可以說這個語句具體該如何執(zhí)行就已經(jīng)定下來噩茄。
5) 執(zhí)行器
當(dāng)選擇了執(zhí)行方案后，MySQL 就準(zhǔn)備開始執(zhí)行了复颈，首先執(zhí)行前會校驗該用戶有沒有權(quán)限绩聘，如果沒有權(quán)限沥割，就會返回錯誤信息，如果有權(quán)限凿菩，就會去調(diào)用引擎的接口机杜，返回接口執(zhí)行的結(jié)果。
二 語句分析
2.1 查詢語句
說了以上這么多衅谷，那么究竟一條 sql 語句是如何執(zhí)行的呢椒拗？其實我們的 sql 可以分為兩種，一種是查詢获黔，一種是更新（增加蚀苛，更新，刪除）玷氏。我們先分析下查詢語句堵未，語句如下：
select * from tb_student A where A.age='18' and A.name=' 張三 ';
結(jié)合上面的說明，我們分析下這個語句的執(zhí)行流程：
先檢查該語句是否有權(quán)限盏触，如果沒有權(quán)限渗蟹，直接返回錯誤信息，如果有權(quán)限赞辩，在 MySQL8.0 版本以前雌芽，會先查詢緩存，以這條 sql 語句為 key 在內(nèi)存中查詢是否有結(jié)果辨嗽，如果有直接緩存世落，如果沒有，執(zhí)行下一步召庞。
通過分析器進行詞法分析，提取 sql 語句的關(guān)鍵元素来破，比如提取上面這個語句是查詢 select篮灼，提取需要查詢的表名為 tb_student,需要查詢所有的列，查詢條件是這個表的 id='1'徘禁。然后判斷這個 sql 語句是否有語法錯誤诅诱，比如關(guān)鍵詞是否正確等等，如果檢查沒問題就執(zhí)行下一步送朱。
-
接下來就是優(yōu)化器進行確定執(zhí)行方案娘荡，上面的 sql 語句，可以有兩種執(zhí)行方案：
a.先查詢學(xué)生表中姓名為“張三”的學(xué)生驶沼，然后判斷是否年齡是 18炮沐。 b.先找出學(xué)生中年齡 18 歲的學(xué)生，然后再查詢姓名為“張三”的學(xué)生回怜。那么優(yōu)化器根據(jù)自己的優(yōu)化算法進行選擇執(zhí)行效率最好的一個方案（優(yōu)化器認為大年，有時候不一定最好）。那么確認了執(zhí)行計劃后就準(zhǔn)備開始執(zhí)行了翔试。
進行權(quán)限校驗，如果沒有權(quán)限就會返回錯誤信息垦缅，如果有權(quán)限就會調(diào)用數(shù)據(jù)庫引擎接口，返回引擎的執(zhí)行結(jié)果壁涎。
2.2 更新語句
以上就是一條查詢 sql 的執(zhí)行流程凡恍，那么接下來我們看看一條更新語句如何執(zhí)行的呢粹庞？sql 語句如下：
update tb_student A set A.age='19' where A.name=' 張三 ';
我們來給張三修改下年齡，在實際數(shù)據(jù)庫肯定不會設(shè)置年齡這個字段的庞溜，不然要被技術(shù)負責(zé)人打的。其實條語句也基本上會沿著上一個查詢的流程走流码，只不過執(zhí)行更新的時候肯定要記錄日志啦，這就會引入日志模塊了漫试，MySQL 自帶的日志模塊式 binlog（歸檔日志） ，所有的存儲引擎都可以使用驾荣，我們常用的 InnoDB 引擎還自帶了一個日志模塊 redo log（重做日志），我們就以 InnoDB 模式下來探討這個語句的執(zhí)行流程播掷。流程如下：
- 先查詢到張三這一條數(shù)據(jù)审编，如果有緩存，也是會用到緩存歧匈。
- 然后拿到查詢的語句垒酬，把 age 改為 19，然后調(diào)用引擎 API 接口件炉，寫入這一行數(shù)據(jù)勘究，InnoDB 引擎把數(shù)據(jù)保存在內(nèi)存中，同時記錄 redo log斟冕，此時 redo log 進入 prepare 狀態(tài)口糕，然后告訴執(zhí)行器，執(zhí)行完成了磕蛇，隨時可以提交走净。
- 執(zhí)行器收到通知后記錄 binlog券时，然后調(diào)用引擎接口，提交 redo log 為提交狀態(tài)伏伯。
- 更新完成橘洞。
這里肯定有同學(xué)會問，為什么要用兩個日志模塊说搅，用一個日志模塊不行嗎?
這是因為最開始 MySQL 并沒與 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) 炸枣，MySQL 自帶的引擎是 MyISAM，但是我們知道 redo log 是 InnoDB 引擎特有的弄唧，其他存儲引擎都沒有适肠，這就導(dǎo)致會沒有 crash-safe 的能力(crash-safe 的能力即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失)候引，binlog 日志只能用來歸檔侯养。
并不是說只用一個日志模塊不可以，只是 InnoDB 引擎就是通過 redo log 來支持事務(wù)的澄干。那么逛揩，又會有同學(xué)問，我用兩個日志模塊麸俘，但是不要這么復(fù)雜行不行辩稽，為什么 redo log 要引入 prepare 預(yù)提交狀態(tài)？這里我們用反證法來說明下為什么要這么做从媚？
- 先寫 redo log 直接提交逞泄，然后寫 binlog，假設(shè)寫完 redo log 后拜效，機器掛了喷众，binlog 日志沒有被寫入，那么機器重啟后紧憾，這臺機器會通過 redo log 恢復(fù)數(shù)據(jù)到千，但是這個時候 bingog 并沒有記錄該數(shù)據(jù)，后續(xù)進行機器備份的時候稻励，就會丟失這一條數(shù)據(jù)父阻，同時主從同步也會丟失這一條數(shù)據(jù)愈涩。
- 先寫 binlog望抽，然后寫 redo log煤篙，假設(shè)寫完了 binlog辑奈，機器異常重啟了，由于沒有 redo log鸠窗，本機是無法恢復(fù)這一條記錄的，但是 binlog 又有記錄躁绸，那么和上面同樣的道理臣嚣，就會產(chǎn)生數(shù)據(jù)不一致的情況硅则。
如果采用 redo log 兩階段提交的方式就不一樣了，寫完 binglog 后暑认，然后再提交 redo log 就會防止出現(xiàn)上述的問題揪垄，從而保證了數(shù)據(jù)的一致性饥努。那么問題來了，有沒有一個極端的情況呢驾诈？假設(shè) redo log 處于預(yù)提交狀態(tài)溶浴，binglog 也已經(jīng)寫完了，這個時候發(fā)生了異常重啟會怎么樣呢闯两？
這個就要依賴于 MySQL 的處理機制了漾狼，MySQL 的處理過程如下：
- 判斷 redo log 是否完整饥臂，如果判斷是完整的，就立即提交稽煤。
- 如果 redo log 只是預(yù)提交但不是 commit 狀態(tài)，這個時候就會去判斷 binlog 是否完整酵熙，如果完整就提交 redo log, 不完整就回滾事務(wù)匾二。
這樣就解決了數(shù)據(jù)一致性的問題。
三 總結(jié)
- MySQL 主要分為 Server 層和引擎層借嗽，Server 層主要包括連接器转培、查詢緩存、分析器惨寿、優(yōu)化器裂垦、執(zhí)行器肌索，同時還有一個日志模塊（binlog），這個日志模塊所有執(zhí)行引擎都可以共用,redolog 只有 InnoDB 有晕换。
- 引擎層是插件式的闸准，目前主要包括梢灭，MyISAM,InnoDB,Memory 等。
- 查詢語句的執(zhí)行流程如下：權(quán)限校驗（如果命中緩存）---》查詢緩存---》分析器---》優(yōu)化器---》權(quán)限校驗---》執(zhí)行器---》引擎
- 更新語句執(zhí)行流程如下：分析器----》權(quán)限校驗----》執(zhí)行器---》引擎---redo log(prepare 狀態(tài)---》binlog---》redo log(commit狀態(tài))
四 參考
- MySQL 5.6參考手冊:https://dev.MySQL.com/doc/refman/5.6/en/
