廢話不多說先來張**釋
update t set value = value+1 where id =2
複製**
我想可能大部分人看完這圖，思考片刻，接下來的就不需要在繼續看了，但是考慮到部分朋友還是新手（包括自己）以及後面複習，還是稍微嘮叨一段。
首先，上圖中深色背景的表示在執行器中執行，也就是server層，淺色的是在innodb引擎中執行。
由於很多朋友並不是專業的dba或者對mysql內部原理並不是特別清晰，所以先對redolog和binlog做簡單的介紹。
下面以文字的方式再次描述一下update t set value = value+1 where id =2的過程。
詞法分析器識別出事update語句；
執行器去innodb中進行查詢，找到滿足id = 2 的資料；
執行器將value的值加1；
執行器讓innodb將剛剛的新值寫入到innodb的記憶體中；
innodb在redolog中加入一條記錄，並把該記錄的狀態設定為prepare；
執行器經「update t set value = value+1 where id =2」 寫入到binlog中；
此時提交事務，將redolog中prepare的的記錄狀態設為commit，並且將記憶體中的新資料刷入磁碟。
以上就是比較簡單的過程理解，那麼為啥要分開寫redolog呢？即傳說中的兩階段提交？這裡再做個簡單的分析。
首先對這種方式的好處做個總結：保證以上所有的過程如果出現mysql例項奔潰都不會導致事務的丟失或異常。接下來分析一下這麼做的具體原因：
如果是第5步之前crash，就是還沒寫任何日誌，那麼事務就不存在，在恢復後從redolog和binlog中都不會有任何的問題；
如果寫完redolog 的prepare出現了crash，那麼恢復時，通過redolog和binlog的對比，會發現只要乙個prepare的日誌，那麼會將事務進行回滾，保證redolog和binlog的統一；
如果寫完binlog後出現crash，那麼恢復時，會進行根據binlog日誌對redolog進行補償，對redolog之前prepare的記錄修改為commit狀態，事務得到保證；
最後commit後crash，redolog和binlog都是正常的。
redolog只出現在inndb中，而且是迴圈寫的，不能持久儲存，所以暫時不能用redolog來做主從或者資料備份
Mysql Update語句的詳細用法
以下的文章主要介紹的是mysql update 語句的實際用法，我們首先是以單錶的update語句來引出實現mysql update 語句的實際方案，以下就是文章的詳細內容描述，望你看完之後會有收穫。單錶的mysql update語句 update low priority ignore tbl n...
mysql update語句與limit的結合使用
mysql的update語句只支援更新前多少行，不支援從某行到另一行，比如 update tb name set column name test order by id asc limit 30 更新前30行的某個字段內容，沒什麼問題。update tb name set column name ...
Mysql update語句賦值巢狀select
update a set col select col from a where id 5 where id 5 and id 10 報錯了error 1093 hy000 you can t specify target table a for update in from clause 發現是 ...