mysql innodb存儲引擎中一個事務的完整流程分析

這篇文章主要講解了“mysql innodb存儲引擎中一個事務的完整流程分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“mysql innodb存儲引擎中一個事務的完整流程分析”吧！

首先說下innodb的事務日志概念：

ib_logfile文件就是innodb的事務日志，可以理解是INNODB的REDO日志，當數據庫異常關閉的時候，innodb存儲引擎下的mysql借助事務日志來完成實例恢復，即前滾和回滾來保證數據庫一致性；

區別于binlog日志又叫二進制日志文件，它會將mysql中所有修改數據庫數據的Query以二進制的形式記錄到日志文件中,如：create,insert,drop,update等;（對于select操作則不會被記錄到binlog里，因為它并沒有修改數據庫的數據），binlog主要是用于保證數據完整的，如主從備份，通過從binlog文件中讀取操作Query來在salve機上進行同樣的操作，保證主從同步，同時也可以作為恢復數據的工具。

Innodb還有另外一個日志Undo log，但Undo log是存放在共享表空間里面的（ibdata*文件，存儲的是check point日志序列號）。

InnoDB 日志緩沖區（InnoDB Log Buffer）：這是 InnoDB 存儲引擎的事務日志所使用的緩沖區。類似于 Binlog Buffer，InnoDB 在寫事務日志的時候，為了提高性能，也是先將信息寫入 Innofb Log Buffer 中，當滿足 innodb_flush_log_trx_commit 參數所設置的相應條件（或者日志緩沖區寫滿）之后，才會將日志寫到文件（或者同步到磁盤）中。可以通過 innodb_log_buffer_size 參數設置其可以使用的最大內存空間；

下面重點講解 innodb_flush_log_trx_commit 參數：下圖可以清楚的展現出該參數設置成不同值時log刷新的不同過程；

針對這張圖第一個箭頭代表著每次commit的時候，事務日志到達的地方， 然后第二個箭頭，代表刷新到磁盤永久保存的過程,  后面的fsync every commit、fsync every second 、fsync every second 是在分別形容第二個箭頭刷新的條件。

然后還需要注意的：宏觀上寫進logfile就是寫進磁盤了。但是微觀上寫進logfile是先寫進了os cahce，然后再刷新到raid cache(前提是做了raid)最后到磁盤。

具體分析innodb_flush_log_at_trx_commit=N的意義：

innodb_flush_log_at_trx_commit=0，每次commit時,事務日志寫進了innodb  log buffer ,然后每秒Log Thread 會將事務日志從innodb log  buffer刷新到ib_ogfile(也就刷新到了磁盤）。當innodb_flush_log_at_trx_commit設置為0，mysqld進程的崩潰會導致上一秒鐘所有事務數據的丟失，這是因為每次commit，事務日志只是寫進了innodb log buffer 中，然后是每秒才將innodb log buffer 中的事務日志刷新到磁盤永久保存，所以mysqld進程的崩潰時，innodb log buffer可能會有一秒的日志沒有刷新出來，但是在這種情況下，MySQL性能最好；

innodb_flush_log_at_trx_commit=2，每次commit時，事務日志寫進了innodb  log buffer，并同時接著寫進os cache, 也就是說每次commit，事務日志寫進了os cache中， 然后每秒從os cache刷新到ib_logfile(也就是刷新到了磁盤）。當innodb_flush_log_at_trx_commit設置為2，只有在操作系統崩潰或者系統掉電的情況下，上一秒鐘所有事務數據才可能丟失，因為每次commit，事務日志已經進入了os cache,所以mysqld崩潰，事務日志是不會丟失的；

innodb_flush_log_at_trx_commit設置為1，這是最安全的設置，同時由于頻繁的io操作，導致效率是最差的，這時候不管是mysqld，還是操作系統崩潰，都不會丟數據，這是因為每次commit,事務日志都刷新到了磁盤永久保存了；

選取的原則：

對于一些數據一致性和完整性要求不高的應用，配置為 2 就足夠了；如果為了最高性能，可以設置為 0。有些應用，如支付服務，對一致性和完整性要求很高，所以即使最慢，也最好設置為 1.。

然后介紹參數sync_binlog ：

sync_binlog =  N： 控制的是從binlog buffer中刷新binlog到底層binlog文件（也就是刷新到底層磁盤）

N>0    每向二進制日志文件寫入N條SQL或N個事務后，則把二進制日志文件的數據刷新到磁盤上； 

N=0    不主動刷新二進制日志文件的數據到磁盤上，而是由操作系統決定； 

推薦配置組合： 

1）innodb_flush_log_at_trx_commit=1同時sync_binlog =1

這就是所謂的雙1設置：這種配置適合數據安全性要求非常高，而且磁盤IO寫能力足夠支持業務，比如充值消費系統，銀行業務； 

2）innodb_flush_log_at_trx_commit=1同時sync_binlog =0

這種設置：保證了事務日志是全的，也就保證可以實例恢復，即前滾和回滾，適合數據安全性要求高，磁盤IO寫能力不太富余；

3））innodb_flush_log_at_trx_commit=2或者0同時sync_binlog =2或者m(0<m<100) </m<100)<>

這種設置：適合數據安全性有要求，允許丟失一點事務日志；

4）innodb_flush_log_at_trx_commit=0同時sync_binlog =0

這種配置適合 ：磁盤IO寫能力有限，對數據安全要求較低，例如：日志性登記業務； 

感謝各位的閱讀，以上就是“mysql innodb存儲引擎中一個事務的完整流程分析”的內容了，經過本文的學習后，相信大家對mysql innodb存儲引擎中一個事務的完整流程分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！