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

為無錫等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及無錫網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、無錫網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

首先說下innodb的事務(wù)日志概念：

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

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

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

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

下面重點(diǎn)講解 innodb_flush_log_trx_commit 參數(shù)：下圖可以清楚的展現(xiàn)出該參數(shù)設(shè)置成不同值時log刷新的不同過程；

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

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

具體分析innodb_flush_log_at_trx_commit=N的意義：

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

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

innodb_flush_log_at_trx_commit設(shè)置為1，這是最安全的設(shè)置，同時由于頻繁的io操作，導(dǎo)致效率是最差的，這時候不管是mysqld，還是操作系統(tǒng)崩潰，都不會丟數(shù)據(jù)，這是因?yàn)槊看蝐ommit,事務(wù)日志都刷新到了磁盤永久保存了；

選取的原則：

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

然后介紹參數(shù)sync_binlog ：

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

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

N=0    不主動刷新二進(jìn)制日志文件的數(shù)據(jù)到磁盤上，而是由操作系統(tǒng)決定； 

推薦配置組合： 

1）innodb_flush_log_at_trx_commit=1同時sync_binlog =1

這就是所謂的雙1設(shè)置：這種配置適合數(shù)據(jù)安全性要求非常高，而且磁盤IO寫能力足夠支持業(yè)務(wù)，比如充值消費(fèi)系統(tǒng)，銀行業(yè)務(wù)； 

2）innodb_flush_log_at_trx_commit=1同時sync_binlog =0

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

3））innodb_flush_log_at_trx_commit=2或者0同時sync_binlog =2或者m(0

這種設(shè)置：適合數(shù)據(jù)安全性有要求，允許丟失一點(diǎn)事務(wù)日志；

4）innodb_flush_log_at_trx_commit=0同時sync_binlog =0

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

感謝各位的閱讀，以上就是“mysql innodb存儲引擎中一個事務(wù)的完整流程分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對mysql innodb存儲引擎中一個事務(wù)的完整流程分析這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！