案例描述：

　　一個普通的事務提交，在應用裡面會提示commit超時，失敗。

一、理論知識

1、關於commit原理，事務提交過程

　　1、尋找修改的資料頁：

　　　　1、如果該資料頁在記憶體中，則直接是記憶體讀；

　　　　2、如果該資料頁記憶體中沒有，物理讀，就從磁碟調入記憶體；

　　2、磁碟中的undo頁調入記憶體；

　　3、先將原來的資料存入undo，然後修改資料(資料頁成髒頁)；

　　4、修改資料的資訊生成redo資料存入log_buffer(記憶體buffer_pool的一個空間，預設16M)中；

mysql> show variables like '%log_buffer%
 
';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+
1 row in set (0.01 sec)

　　5、log_buffer通過log執行緒(後臺執行緒，非常勤快)，持續不斷的將redo資訊寫入disk的innodb_log_file中；

mysql> show variables like
 
 'innodb_log_file%';
+---------------------------+----------+
| Variable_name             | Value    |
+---------------------------+----------+
| innodb_log_file_size      | 50331648 |
| innodb_log_files_in_group | 2        |
+---------------------------+----------+
2 rows in set (0.01 sec)

　　6、事務提交，刻意觸發log執行緒，將剩餘的log_buffer中的redo資料資訊寫入磁碟中，資料量已剩不多，寫完提交成功。

注意：

　　1、修改記錄前，一定要先寫日誌；

　　　　“日誌先行”，這是資料庫最基本的原則。

　　2、事務提交過程中，一定要保證日誌先落盤，才能算事務提交完成。

　　3、意外掉電，記憶體髒頁丟失，但是磁碟的innodb_log_file中存放了redo日誌資訊，待重啟伺服器，MySQL通過讀取磁碟的log_files資料，自動將資料的修改重新跑一邊。

Q：為什麼mysql commit速度總是很快，儘管事務修改的資料量可能很大？

A：

　　因為事務提交，並不是對磁碟資料進行修改，而是將修改資料的redo資訊通過後臺log執行緒寫入磁碟的redo logfile中，完成mysql commit，無論事務修改的資料量有多大，這個過程速度是很快的。

　　而記憶體中的髒塊，也就是修改後的資料頁，正常情況下是由後臺相關write執行緒週期性的將髒頁資料刷入磁碟中，保證innodb buffer pool有足夠的乾淨塊、可用塊。

2、關於rollback原理，回滾過程

　　1、MySQL讀取記憶體中undo頁資訊

　　2、通過undo資訊找到髒頁，反著對資料進行修改

　　3、do、undo的時間相同，且都會產成redo資訊

　　4、事務提交

MySQL回滾處理機制：

　　如果執行緒中斷，事務沒有提交，undo會將記錄此資訊，待另一會話程序連上，檢視該塊資料資訊，MySQL自動回滾進行資料頁修改，然後被讀取。也就是說為了避免系統因為rollback被hang住，通過直接殺死程序的方式，中斷事務，等待後來者要讀取該資料資訊時進行回滾，再返回結果。

Q：rollback為什麼有時候很慢，rollback的風險和風險避免方式？

A：

　　rollback的時間取決於回滾前事務修改資料的時間，處理量大回滾時間長，處理量小回滾時間短。

　　1、rollback風險：容易導致系統被hang住；

　　2、風險避免方式：直接殺死會話程序或是mysql程序。

3、儲存寫入效能分析

Q：mysql commit，儲存為什麼寫速度能夠保持在0ms，極少出現1ms情況？

A：

　　對於儲存來說，寫效能相當高：假設儲存cache總有空閒空間的情況下，事務提交，將log buffer中剩餘的很少的redo資料寫入儲存cache，即為完成mysql commit，這個過程是相當快的(能夠保持在0ms，極少出現1ms情況)，後續redo資料由cache寫入磁碟的過程是後臺進行。

4、儲存級別的災備(同城災備)

　　1、災備同步過程：commit

　　　　1、redo、binlog寫入本地儲存cache；

　　　　2、通過網路同步binlog寫入遠端同步的伺服器的儲存cache中；

　　　　3、響應本地資料庫；

　　　　4、事務提交成功；

　　2、風險：

　　　　網路出現問題(訊號斷續，纜線斷了)，導致寫hang住，commit超時失敗。

　　3、解決：

　　　　通過超時設定，網路中斷超過限制，自動將同步改為災備非同步，儘可能少的影響業務commit超時失敗。

二、分析與處理

　　儲存寫效能比較差，很多時段會達到5ms，甚至於10ms以上

　　　　備註：災備同步已經停止的情況下。

1、儲存中BBU問題，出現監控BBU的bug；

　　解決：重啟BBU，不行就更新BBU。

2、cache被佔滿

　　1、海量資料寫入，commit資料佔滿cache；

　　2、硬碟I/O異常，異常SQL導致的海量物理讀；

　　解決：索引優化。

3、儲存效能差

　　解決：找老闆掏錢，更換優質裝置。