查詢語(yǔ)句
sql 語(yǔ)句分為兩種惑艇，一種是查詢蒿辙，一種是更新（增加，更新滨巴，刪除）思灌。先分析下查詢語(yǔ)句，語(yǔ)句如下：
select * from tb_student A where A.age = '18' and A.name = '張三';
結(jié)合上面的說(shuō)明恭取，我們分析下這個(gè)語(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)化器會(huì)根據(jù)自己的優(yōu)化算法選擇執(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é)果。
更新語(yǔ)句
sql 語(yǔ)句如下：
update tb_student A set A.age = '19' where A.name = '張三';
這條語(yǔ)句也基本上會(huì)沿著上一個(gè)查詢的流程走蟹倾，只不過(guò)執(zhí)行更新的時(shí)候肯定要先記錄日志匣缘，這就會(huì)引入日志模塊，MySQL 自帶的日志模塊式 binlog（歸檔日志） 鲜棠，所有的存儲(chǔ)引擎都可以使用肌厨，我們常用的 InnoDB 引擎還自帶了一個(gè)日志模塊 redo log（重做日志），這里就以 InnoDB 模式下來(lái)探討這個(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)
- 更新完成
這里有人會(huì)問(wèn)颇玷，為什么要用兩個(gè)日志模塊，用一個(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)歸檔。
并不是說(shuō)只用一個(gè)日志模塊不可以廓旬，只是 InnoDB 引擎就是通過(guò) redo log 來(lái)支持事務(wù)的哼审。那么，又會(huì)有同學(xué)問(wèn)孕豹，我用兩個(gè)日志模塊涩盾，但是不要這么復(fù)雜行不行，為什么 redo log 要引入 prepare 預(yù)提交狀態(tài)巩步？這里我們用反證法來(lái)說(shuō)明下為什么要這么做旁赊？
- 先寫 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ù)的一致性哲思。那么問(wèn)題來(lái)了潮孽，有沒(méi)有一個(gè)極端的情況呢疯潭？假設(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)題闪湾。
