查詢語句
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í)行下一步。
通過分析器進(jìn)行詞法分析，提取 sql 語句的關(guān)鍵元素，比如提取上面這個語句是查詢 select，提取需要查詢的表名為 tb_student，需要查詢所有的列，查詢條件是這個表的 id='1'。然后判斷這個 sql 語句是否有語法錯誤，比如關(guān)鍵詞是否正確等等，如果檢查沒問題就執(zhí)行下一步。
接下來就是優(yōu)化器進(jìn)行確定執(zhí)行方案，上面的 sql 語句，可以有兩種執(zhí)行方案：
- a. 先查詢學(xué)生表中姓名為“張三”的學(xué)生，然后判斷是否年齡是 18
- b. 先找出學(xué)生中年齡 18 歲的學(xué)生，然后再查詢姓名為“張三”的學(xué)生
優(yōu)化器會根據(jù)自己的優(yōu)化算法選擇執(zhí)行效率最好的一個方案（優(yōu)化器認(rèn)為，有時候不一定是最好）。那么確認(rèn)了執(zhí)行計(jì)劃后，就準(zhǔn)備開始執(zhí)行了。
進(jìn)行權(quán)限校驗(yàn)，如果沒有權(quán)限就會返回錯誤信息，如果有權(quán)限就會調(diào)用數(shù)據(jù)庫引擎接口，返回引擎的執(zhí)行結(jié)果。
更新語句
sql 語句如下：
update tb_student A set A.age = '19' where A.name = '張三';
這條語句也基本上會沿著上一個查詢的流程走，只不過執(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 進(jìn)入 prepare 狀態(tài)，然后告訴執(zhí)行器，執(zhí)行完成了，隨時可以提交
- 執(zhí)行器收到通知后記錄 binlog，然后調(diào)用引擎接口，提交 redo log 為提交狀態(tài)
- 更新完成
這里有人會問，為什么要用兩個日志模塊，用一個日志模塊不行嗎?
這是因?yàn)樽铋_始 MySQL 并沒有 InnoDB 引擎( InnoDB 引擎是其他公司以插件的形式插入 MySQL 的) ，MySQL 自帶的引擎是 MyISAM，但是我們知道 redo log 是 InnoDB 引擎特有的，其他存儲引擎都沒有，這就導(dǎo)致會沒有 crash-safe 的能力(crash-safe 能力，即使數(shù)據(jù)庫發(fā)生異?；蛘咧貑ⅲ疤峤坏挠涗浂疾粫G失)，而 binlog 日志只能用來歸檔。
并不是說只用一個日志模塊不可以，只是 InnoDB 引擎就是通過 redo log 來支持事務(wù)的。那么，又會有同學(xué)問，我用兩個日志模塊，但是不要這么復(fù)雜行不行，為什么 redo log 要引入 prepare 預(yù)提交狀態(tài)？這里我們用反證法來說明下為什么要這么做？
- 先寫 redo log 直接提交，然后寫 binlog，假設(shè)寫完 redo log 后，機(jī)器掛了，binlog 日志沒有被寫入，那么機(jī)器重啟后，這臺機(jī)器會通過 redo log 恢復(fù)數(shù)據(jù)，但是這個時候 bingog 并沒有記錄該數(shù)據(jù)，后續(xù)進(jìn)行機(jī)器備份的時候，就會丟失這一條數(shù)據(jù)，同時主從同步也會丟失這一條數(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ù)的一致性。那么問題來了，有沒有一個極端的情況呢？假設(shè) redo log 處于預(yù)提交狀態(tài)，binglog 也已經(jīng)寫完了，這個時候發(fā)生了異常重啟會怎么樣呢？ 這個就要依賴于 MySQL 的處理機(jī)制了，MySQL 的處理過程如下：
- 判斷 redo log 是否完整，如果判斷是完整的，就立即提交
- 如果 redo log 只是預(yù)提交但不是 commit 狀態(tài)，這個時候就會去判斷 binlog 是否完整，如果完整就提交 redo log, 不完整就回滾事務(wù)
這樣就解決了數(shù)據(jù)一致性的問題。
