共計 2633 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要講解了“mysql innodb 存儲引擎中一個事務的完整流程分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“mysql innodb 存儲引擎中一個事務的完整流程分析”吧！
首先說下 innodb 的事務日志概念：
ib_logfile 文件就是 innodb 的事務日志，可以理解是 INNODB 的 REDO 日志，當數(shù)據(jù)庫異常關閉的時候，innodb 存儲引擎下的 mysql 借助事務日志來完成實例恢復，即前滾和回滾來保證數(shù)據(jù)庫一致性；
區(qū)別于 binlog 日志又叫二進制日志文件，它會將 mysql 中所有修改數(shù)據(jù)庫數(shù)據(jù)的 Query 以二進制的形式記錄到日志文件中, 如：create,insert,drop,update 等;（對于 select 操作則不會被記錄到 binlog 里，因為它并沒有修改數(shù)據(jù)庫的數(shù)據(jù)），binlog 主要是用于保證數(shù)據(jù)完整的，如主從備份，通過從 binlog 文件中讀取操作 Query 來在 salve 機上進行同樣的操作，保證主從同步，同時也可以作為恢復數(shù)據(jù)的工具。
Innodb 還有另外一個日志 Undo log，但 Undo log 是存放在共享表空間里面的（ibdata* 文件，存儲的是 check point 日志序列號）。
InnoDB 日志緩沖區(qū)（InnoDB Log Buffer）：這是 InnoDB 存儲引擎的事務日志所使用的緩沖區(qū)。類似于 Binlog Buffer，InnoDB 在寫事務日志的時候，為了提高性能，也是先將信息寫入 Innofb Log Buffer 中，當滿足 innodb_flush_log_trx_commit 參數(shù)所設置的相應條件（或者日志緩沖區(qū)寫滿）之后，才會將日志寫到文件（或者同步到磁盤）中?？梢酝ㄟ^ innodb_log_buffer_size 參數(shù)設置其可以使用的最大內存空間；
下面重點講解 innodb_flush_log_trx_commit 參數(shù)：下圖可以清楚的展現(xiàn)出該參數(shù)設置成不同值時 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 進程的崩潰會導致上一秒鐘所有事務數(shù)據(jù)的丟失，這是因為每次 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，只有在操作系統(tǒng)崩潰或者系統(tǒng)掉電的情況下，上一秒鐘所有事務數(shù)據(jù)才可能丟失，因為每次 commit，事務日志已經進入了 os cache, 所以 mysqld 崩潰，事務日志是不會丟失的；
innodb_flush_log_at_trx_commit 設置為 1，這是最安全的設置，同時由于頻繁的 io 操作，導致效率是最差的，這時候不管是 mysqld，還是操作系統(tǒng)崩潰，都不會丟數(shù)據(jù)，這是因為每次 commit, 事務日志都刷新到了磁盤永久保存了；
選取的原則：
對于一些數(shù)據(jù)一致性和完整性要求不高的應用，配置為 2 就足夠了；如果為了最高性能，可以設置為 0。有些應用，如支付服務，對一致性和完整性要求很高，所以即使最慢，也最好設置為 1.。
然后介紹參數(shù) sync_binlog：
sync_binlog = N： 控制的是從 binlog buffer 中刷新 binlog 到底層 binlog 文件（也就是刷新到底層磁盤）
N 0 每向二進制日志文件寫入 N 條 SQL 或 N 個事務后，則把二進制日志文件的數(shù)據(jù)刷新到磁盤上；
N=0 不主動刷新二進制日志文件的數(shù)據(jù)到磁盤上，而是由操作系統(tǒng)決定；
推薦配置組合：
1）innodb_flush_log_at_trx_commit= 1 同時 sync_binlog =1
這就是所謂的雙 1 設置：這種配置適合數(shù)據(jù)安全性要求非常高，而且磁盤 IO 寫能力足夠支持業(yè)務，比如充值消費系統(tǒng)，銀行業(yè)務；
2）innodb_flush_log_at_trx_commit= 1 同時 sync_binlog =0
這種設置：保證了事務日志是全的，也就保證可以實例恢復，即前滾和回滾，適合數(shù)據(jù)安全性要求高，磁盤 IO 寫能力不太富余；
3））innodb_flush_log_at_trx_commit= 2 或者 0 同時 sync_binlog = 2 或者 m(0 m 100) /m 100)
這種設置：適合數(shù)據(jù)安全性有要求，允許丟失一點事務日志；
4）innodb_flush_log_at_trx_commit= 0 同時 sync_binlog =0
這種配置適合：磁盤 IO 寫能力有限，對數(shù)據(jù)安全要求較低，例如：日志性登記業(yè)務；
感謝各位的閱讀，以上就是“mysql innodb 存儲引擎中一個事務的完整流程分析”的內容了，經過本文的學習后，相信大家對 mysql innodb 存儲引擎中一個事務的完整流程分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
