執行器和 innodb 引擎在執行這個簡單的 update 語句時的內部流程。
1、執行器先找引擎取 id=2 這一行。id 是主鍵，引擎直接用樹搜尋找到這一行。如果 id=2 這一行所在的資料頁本來就在記憶體中，就直接返回給執行器；否則，需要先從磁碟讀入記憶體，然後再返回。
2、執行器拿到引擎給的行資料，把這個值加上 1，比如原來是 n，現在就是 n+1，得到新的一行資料，再呼叫引擎介面寫入這行新資料。
3、引擎將這行新資料更新到記憶體中，同時將這個更新操作記錄到 redo log 裡面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。
4、執行器生成這個操作的 binlog，並把 binlog 寫入磁碟。
5、執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。
mysql 裡面最重要的兩個日誌，即物理日誌 redo log 和邏輯日誌 binlog。
1、redo log 用於保證 crash-safe 能力。innodb_flush_log_at_trx_commit 這個引數設定成 1 的時候，表示每次事務的 redo log 都直接持久化到磁碟。這個引數我建議你設定成 1，這樣可以保證 mysql 異常重啟之後資料不丟失。
2、sync_binlog 這個引數設定成 1 的時候，表示每次事務的 binlog 都持久化到磁碟。這個引數我也建議你設定成 1，這樣可以保證 mysql 異常重啟之後 binlog 不丟失。
3、mysql 日誌系統密切相關的「兩階段提交」。兩階段提交是跨系統維持資料邏輯一致性時常用的乙個方案。
from:
優化一條UPDATE語句
最近見到一條開發人員寫的update語句,覺得沒什麼不對,可又覺得有地方不對,因為效能低下.update a set col2,col3 select col1,t from b where b.col1 a.col1 where exists select b.col1 from b where ...
一條SQL的改寫
最近需求中需要實現這樣乙個功能 找主活動是未鎖定的，且已確認的子活動資料，表中資料的分布是這樣的 表中資料存放結構 主活動1 沒鎖定 子活動 主11 已確認 子活動 主22 已確認 主活動2 鎖定 子活動 主21 未確認 子活動 主22 已確認 1用 not exist實現 select t1.at...
mysql一條語句update多條記錄
通常情況下，我們會使用以下sql語句來更新字段值 update mytable set myfield value where other field other value 但是，如果你想更新多行資料，並且每行記錄的各字段值都是各不一樣，你會怎麼辦呢？剛開始你可能會想到使用迴圈執行多條update...