MySQL InnoDB 日誌管理機制中的MTR和日誌刷盤
1.MTR(mini-transaction)
在MySQL的 InnoDB日誌管理機制中，有一個很重要的概念就是MTR。MTR是InnoDB存儲擎中一個很重要的用來保證物理寫的完整性和持久性的機制。
先看下MTR在MysQL架構中的位置。
MTR是上面的邏輯層與下面物理層的交互窗口，同時也是用來保證下層物理數據正確性、完整性及持久性的機制。
2.日誌刷盤的觸發條件
| 觸發條件 | 描述 |
| 時間 | 線程默認每秒刷新一次。 |
| 空間 | Log Buffer空間用完了 |
| Check Point | checkPoint的時機較多，既有空間觸發也有時間觸發。主要分為
Sharp Checkpoint和Fuzzy Checkpoint |
| 強一致事務要求 | 根據參數innodb_flush_log_at_trx_commit值不同，產生不同的行為。 |
3. innodb_flush_log_at_trx_commit簡單介紹
參數解釋
（部分內容個人理解，特別是我將log file 分為os cache 和 磁盤2種，更多內容還要求證。 ）
0：每次事務提交時，根本不會去刷日誌緩沖區。log buffer將每秒一次地寫入到OS cache的log file中，並且log file的flush(刷到磁盤)上的Log Files操作同時進行。
1：每次事務提交時MySQL都會把log buffer的數據寫入到OS cache的log file，並且flush(刷到磁盤)Log Files中去，該模式為系統默認。
2：每次事務提交時MySQL都會把log buffer的數據寫入到OS cache的log file，但是flush(刷到磁盤)Log Files的操作並不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操作。
註意事項
當設置為0，該模式速度最快，但不太安全，這種設置是最危險的。如果此時運氣不好，mysqld進程的崩潰，那麽對數據庫最新的更新都會丟失，即使事務已經提交了。但一般丟失的數據都是在一秒內產生的。
當設置為1，該模式是最安全的，但也是最慢的一種方式。在mysqld 服務崩潰或者服務器主機crash的情況下，binary log 只有可能丟失最多一個語句或者一個事務。
當設置為2，該模式速度較快，也比0安全，只有在操作系統崩潰或者系統斷電的情況下，上一秒鐘所有事務數據才可能丟失。
此參數可根據業務的可靠性要求進行調整，參數的選擇對性能影響較大。
部分內容觀點來自同行的分享，在此一並感謝！！！
MySQL InnoDB 日誌管理機制中的MTR和日誌刷盤