上一節《查詢語句的執行順序》總體梳理了一下mysql中查詢語句的執行順序，這次梳理一下mysql的修改語句的執行順序
其實修改語句的執行順序跟查詢語句的順序一樣，
1:連接器-處理鏈接，驗證權限
2:查詢緩存-緩存失效，所以不建議在修改頻繁的表上用查詢緩存
3:分析器-詞法分析，語法分析，驗證否和mysql的標準
4:優化器-選擇用那個id查詢符合條件的數據
6:執行器-校驗表權限，調用執行引擎，返回結果
mysql的server層有binLog
innoDB的執行引擎有redoLog
log文件系統是一個非常經典的設計模式
舉個例子，孔乙己所在的咸亨飯店，有很多人賒賬，掌櫃的很忙的時候，不會直接記一筆賒賬記錄在賬本里面，而是在櫃檯上的小黑板上記下這次賒賬的記錄，然後在空閒的時候，再把小黑板上的記錄轉記到賬本里面。這個小黑板的功能，就相當於redoLog
InnoDB的這項優化技術叫WAL。write-ahead-logging.先寫日誌，再寫磁盤。如果mysql出現的異常，之前的操作都會在內存redoLog中和磁盤中，這中能力叫crash-safe。
不過InnoBD的小黑板很大，可以分爲4個，每個黑板1G大小，像個循環鏈表，從頭開始寫，寫到末尾，會把開頭的記錄寫到硬盤裏買呢，然後空餘的空間寫新的操作記錄。
InnoDB的redoLog實現了crash-safe能力，但是InnoDB只是Mysql的一個執行引擎，其餘的執行引擎可能沒有redoLog。所以Mysq在Server層也有自己的日誌系統-binLog，binLog記錄的是update的邏輯操作。
所以在執行update語句的時候，到底發生了什麼呢
1:執行器執行update語句，引擎會先根據索引或者其餘的篩選條件，把符合的結果集返回給執行器，
2：執行器獲取的結果集數據，依次更新，然後調用執行引擎寫入新的數據
3:執行引擎將數據更新到內存中，然後把更新操作寫入redoLog，此時redolog記錄是prepare狀態，告訴執行器隨時可以提交事物
4:執行器把這個update操作寫入binLog，並寫入磁盤
5:執行器調用執行引擎把剛纔的redoLog的狀態改爲commit狀態，更新完成。
很有意思的問題，redoLog和binLog到底有什麼不同呢