mysql innodb引擎執行更新和查詢命令詳細過程

必須結合日誌系統詳解的博客搭配看不然根本看不懂更本無法理解！！！

1.mysql 執行查詢命令

mysql 執行更新命令

1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果 ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器;否則，需要先從磁盤讀入內存，然後再返回。
2. 執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到新的 一行數據，再調用引擎接口寫入這行新數據。
3. 請注意此時引擎並沒有寫入磁盤中，而是引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 裏面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。
4. 執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。
5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交(commit)狀 態，更新完成。

由圖可知redo 日誌存在兩個不同的階段 （兩階段提交） prepare commit 狀態

寫入了binlog再commit

重點理解二個提交階段prepare 和 commit
不要被二個日誌給帶歪了，從二個提交狀態來理解。
我們來說一下，如果重啓會不會帶來問題：

	1.在寫入redolog處於prepare階段後，還沒來的及寫binlog時重啓
		只要處於prepare狀態，mysql重啓後發現是prepare狀態的數據，就會認爲是無效數據，所以不會產生影響
	2.redolog處於prepare階段，binlog也寫完並寫入磁盤，此時還沒commit就重啓。
		這個時候redolog是prepare, binlog也已經完整了，Mysql重啓後，認爲認可這一個事務，會提交掉。

二個階段提交有大作用
不只是誤操作後需要用這個過程來恢復數據。當你需要擴容的時候，也就是需要再 多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用 binlog 來實現的，這個“不一致”就會導致你的線上出現主從數據庫不一致的情況。
簡單說，redo log 和 binlog 都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態 保持邏輯上的一致。