一 MySQL 基礎(chǔ)架構(gòu)分析
1.1 MySQL 基本架構(gòu)概覽
下圖是 MySQL 的一個(gè)簡要架構(gòu)圖瞬浓，從下圖你可以很清晰的看到用戶的 SQL 語句在 MySQL 內(nèi)部是如何執(zhí)行的葱色。
先簡單介紹一下下圖涉及的一些組件的基本作用幫助大家理解這幅圖湖饱，在 1.2 節(jié)中會詳細(xì)介紹到這些組件的作用刃泌。
?連接器： 身份認(rèn)證和權(quán)限相關(guān)(登錄 MySQL 的時(shí)候)妹懒。?查詢緩存: 執(zhí)行查詢語句的時(shí)候创泄，會先查詢緩存（MySQL 8.0 版本后移除烈掠，因?yàn)檫@個(gè)功能不太實(shí)用）。?分析器: 沒有命中緩存的話来候，SQL 語句就會經(jīng)過分析器跷叉，分析器說白了就是要先看你的 SQL 語句要干嘛，再檢查你的 SQL 語句語法是否正確营搅。?優(yōu)化器： 按照 MySQL 認(rèn)為最優(yōu)的方案去執(zhí)行云挟。?執(zhí)行器: 執(zhí)行語句，然后從存儲引擎返回?cái)?shù)據(jù)转质。
簡單來說 MySQL 主要分為 Server 層和存儲引擎層：
?Server 層：主要包括連接器园欣、查詢緩存、分析器休蟹、優(yōu)化器俊庇、執(zhí)行器等，所有跨存儲引擎的功能都在這一層實(shí)現(xiàn)鸡挠，比如存儲過程辉饱、觸發(fā)器、視圖拣展，函數(shù)等彭沼，還有一個(gè)通用的日志模塊 binglog 日志模塊。?存儲引擎： 主要負(fù)責(zé)數(shù)據(jù)的存儲和讀取备埃，采用可以替換的插件式架構(gòu)姓惑，支持 InnoDB、MyISAM按脚、Memory 等多個(gè)存儲引擎于毙，其中 InnoDB 引擎有自有的日志模塊 redolog 模塊。現(xiàn)在最常用的存儲引擎是 InnoDB辅搬，它從 MySQL 5.5.5 版本開始就被當(dāng)做默認(rèn)存儲引擎了唯沮。
1.2 Server 層基本組件介紹
1) 連接器
連接器主要和身份認(rèn)證和權(quán)限相關(guān)的功能相關(guān)，就好比一個(gè)級別很高的門衛(wèi)一樣。
主要負(fù)責(zé)用戶登錄數(shù)據(jù)庫介蛉，進(jìn)行用戶的身份認(rèn)證萌庆，包括校驗(yàn)賬戶密碼，權(quán)限等操作币旧，如果用戶賬戶密碼已通過践险，連接器會到權(quán)限表中查詢該用戶的所有權(quán)限，之后在這個(gè)連接里的權(quán)限邏輯判斷都是會依賴此時(shí)讀取到的權(quán)限數(shù)據(jù)吹菱，也就是說巍虫，后續(xù)只要這個(gè)連接不斷開，即時(shí)管理員修改了該用戶的權(quán)限鳍刷，該用戶也是不受影響的占遥。
2) 查詢緩存(MySQL 8.0 版本后移除)
查詢緩存主要用來緩存我們所執(zhí)行的 SELECT 語句以及該語句的結(jié)果集。
連接建立后倾剿，執(zhí)行查詢語句的時(shí)候，會先查詢緩存蚌成，MySQL 會先校驗(yàn)這個(gè) sql 是否執(zhí)行過前痘，以 Key-Value 的形式緩存在內(nèi)存中，Key 是查詢預(yù)計(jì)担忧，Value 是結(jié)果集芹缔。如果緩存 key 被命中，就會直接返回給客戶端瓶盛，如果沒有命中最欠，就會執(zhí)行后續(xù)的操作，完成后也會把結(jié)果緩存起來惩猫，方便下一次調(diào)用芝硬。當(dāng)然在真正執(zhí)行緩存查詢的時(shí)候還是會校驗(yàn)用戶的權(quán)限，是否有該表的查詢條件轧房。
MySQL 查詢不建議使用緩存拌阴，因?yàn)椴樵兙彺媸г趯?shí)際業(yè)務(wù)場景中可能會非常頻繁，假如你對一個(gè)表更新的話奶镶，這個(gè)表上的所有的查詢緩存都會被清空迟赃。對于不經(jīng)常更新的數(shù)據(jù)來說，使用緩存還是可以的厂镇。
所以纤壁，一般在大多數(shù)情況下我們都是不推薦去使用查詢緩存的。
MySQL 8.0 版本后刪除了緩存的功能捺信，官方也是認(rèn)為該功能在實(shí)際的應(yīng)用場景比較少酌媒，所以干脆直接刪掉了。
3) 分析器
MySQL 沒有命中緩存，那么就會進(jìn)入分析器馍佑，分析器主要是用來分析 SQL 語句是來干嘛的斋否，分析器也會分為幾步：
第一步，詞法分析拭荤，一條 SQL 語句有多個(gè)字符串組成茵臭，首先要提取關(guān)鍵字，比如 select舅世，提出查詢的表旦委，提出字段名，提出查詢條件等等雏亚。做完這些操作后缨硝，就會進(jìn)入第二步。
第二步罢低，語法分析查辩，主要就是判斷你輸入的 sql 是否正確，是否符合 MySQL 的語法网持。
完成這 2 步之后宜岛，MySQL 就準(zhǔn)備開始執(zhí)行了，但是如何執(zhí)行功舀，怎么執(zhí)行是最好的結(jié)果呢萍倡？這個(gè)時(shí)候就需要優(yōu)化器上場了拴签。
4) 優(yōu)化器
優(yōu)化器的作用就是它認(rèn)為的最優(yōu)的執(zhí)行方案去執(zhí)行（有時(shí)候可能也不是最優(yōu)泡躯，這篇文章涉及對這部分知識的深入講解），比如多個(gè)索引的時(shí)候該如何選擇索引台丛，多表查詢的時(shí)候如何選擇關(guān)聯(lián)順序等帖汞。
可以說戴而，經(jīng)過了優(yōu)化器之后可以說這個(gè)語句具體該如何執(zhí)行就已經(jīng)定下來。
5) 執(zhí)行器
當(dāng)選擇了執(zhí)行方案后翩蘸，MySQL 就準(zhǔn)備開始執(zhí)行了填硕，首先執(zhí)行前會校驗(yàn)該用戶有沒有權(quán)限，如果沒有權(quán)限鹿鳖，就會返回錯誤信息扁眯，如果有權(quán)限，就會去調(diào)用引擎的接口翅帜，返回接口執(zhí)行的結(jié)果姻檀。
二 語句分析
2.1 查詢語句
說了以上這么多，那么究竟一條 sql 語句是如何執(zhí)行的呢涝滴？其實(shí)我們的 sql 可以分為兩種绣版，一種是查詢胶台，一種是更新（增加，更新杂抽，刪除）诈唬。我們先分析下查詢語句，語句如下：
select * from tb_student A where A.age='18' and A.name=' 張三 ';
結(jié)合上面的說明缩麸，我們分析下這個(gè)語句的執(zhí)行流程：
先檢查該語句是否有權(quán)限铸磅，如果沒有權(quán)限，直接返回錯誤信息杭朱，如果有權(quán)限阅仔，在 MySQL8.0 版本以前，會先查詢緩存弧械，以這條 sql 語句為 key 在內(nèi)存中查詢是否有結(jié)果八酒，如果有直接緩存，如果沒有刃唐，執(zhí)行下一步羞迷。
通過分析器進(jìn)行詞法分析，提取 sql 語句的關(guān)鍵元素画饥，比如提取上面這個(gè)語句是查詢 select衔瓮，提取需要查詢的表名為 tb_student,需要查詢所有的列，查詢條件是這個(gè)表的 id='1'荒澡。然后判斷這個(gè) sql 語句是否有語法錯誤报辱，比如關(guān)鍵詞是否正確等等与殃，如果檢查沒問題就執(zhí)行下一步单山。
接下來就是優(yōu)化器進(jìn)行確定執(zhí)行方案，上面的 sql 語句幅疼，可以有兩種執(zhí)行方案：
a.先查詢學(xué)生表中姓名為“張三”的學(xué)生米奸，然后判斷是否年齡是 18。
那么優(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)逐工，如果沒有權(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í)際數(shù)據(jù)庫肯定不會設(shè)置年齡這個(gè)字段的哈扮，不然要被技術(shù)負(fù)責(zé)人打的纬纪。其實(shí)條語句也基本上會沿著上一個(gè)查詢的流程走，只不過執(zhí)行更新的時(shí)候肯定要記錄日志啦滑肉，這就會引入日志模塊了包各，MySQL 自帶的日志模塊式 binlog（歸檔日志） ，所有的存儲引擎都可以使用靶庙，我們常用的 InnoDB 引擎還自帶了一個(gè)日志模塊 redo log（重做日志）问畅，我們就以 InnoDB 模式下來探討這個(gè)語句的執(zhí)行流程。流程如下：
?先查詢到張三這一條數(shù)據(jù)惶洲，如果有緩存按声，也是會用到緩存。?然后拿到查詢的語句恬吕，把 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)愧沟。?更新完成蔬咬。
這里肯定有同學(xué)會問，為什么要用兩個(gè)日志模塊沐寺，用一個(gè)日志模塊不行嗎?
這是因?yàn)樽铋_始 MySQL 并沒與 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) 林艘，MySQL 自帶的引擎是 MyISAM，但是我們知道 redo log 是 InnoDB 引擎特有的混坞，其他存儲引擎都沒有狐援，這就導(dǎo)致會沒有 crash-safe 的能力(crash-safe 的能力即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失)究孕，binlog 日志只能用來歸檔啥酱。
并不是說只用一個(gè)日志模塊不可以，只是 InnoDB 引擎就是通過 redo log 來支持事務(wù)的厨诸。那么镶殷，又會有同學(xué)問，我用兩個(gè)日志模塊泳猬，但是不要這么復(fù)雜行不行批钠，為什么 redo log 要引入 prepare 預(yù)提交狀態(tài)宇植？這里我們用反證法來說明下為什么要這么做？
?先寫 redo log 直接提交埋心，然后寫 binlog指郁，假設(shè)寫完 redo log 后，機(jī)器掛了拷呆，binlog 日志沒有被寫入闲坎，那么機(jī)器重啟后，這臺機(jī)器會通過 redo log 恢復(fù)數(shù)據(jù)茬斧，但是這個(gè)時(shí)候 bingog 并沒有記錄該數(shù)據(jù)腰懂，后續(xù)進(jìn)行機(jī)器備份的時(shí)候，就會丟失這一條數(shù)據(jù)项秉，同時(shí)主從同步也會丟失這一條數(shù)據(jù)绣溜。?先寫 binlog，然后寫 redo log娄蔼，假設(shè)寫完了 binlog怖喻，機(jī)器異常重啟了，由于沒有 redo log岁诉，本機(jī)是無法恢復(fù)這一條記錄的锚沸，但是 binlog 又有記錄，那么和上面同樣的道理涕癣，就會產(chǎn)生數(shù)據(jù)不一致的情況哗蜈。
如果采用 redo log 兩階段提交的方式就不一樣了，寫完 binglog 后坠韩，然后再提交 redo log 就會防止出現(xiàn)上述的問題距潘，從而保證了數(shù)據(jù)的一致性。那么問題來了同眯，有沒有一個(gè)極端的情況呢绽昼？假設(shè) redo log 處于預(yù)提交狀態(tài)唯鸭，binglog 也已經(jīng)寫完了须蜗，這個(gè)時(shí)候發(fā)生了異常重啟會怎么樣呢？ 這個(gè)就要依賴于 MySQL 的處理機(jī)制了目溉，MySQL 的處理過程如下：
?判斷 redo log 是否完整明肮，如果判斷是完整的，就立即提交缭付。?如果 redo log 只是預(yù)提交但不是 commit 狀態(tài)柿估，這個(gè)時(shí)候就會去判斷 binlog 是否完整，如果完整就提交 redo log, 不完整就回滾事務(wù)陷猫。
這樣就解決了數(shù)據(jù)一致性的問題秫舌。
