溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
概要：
我們知道InnoDB采用Write Ahead Log策略來防止宕機數據丟失，即事務提交時，先寫重做日志，再修改內存數據頁，這樣就產生了臟頁。既然有重做日志保證數據持久性，查詢時也可以直接從緩沖池頁中取數據，那為什么還要刷新臟頁到磁盤呢？如果重做日志可以無限增大，同時緩沖池足夠大，能夠緩存所有數據，那么是不需要將緩沖池中的臟頁刷新到磁盤。但是，通常會有以下幾個問題：
重做日志被設計成可循環使用，當日志文件寫滿時，重做日志中對應數據已經被刷新到磁盤的那部分不再需要的日志可以被覆蓋重用。
InnoDB引擎通過LSN(Log Sequence Number)來標記版本，LSN是日志空間中每條日志的結束點，用字節偏移量來表示。每個page有LSN，redo log也有LSN，Checkpoint也有LSN。可以通過命令show
engine innodb status來觀察：
Flush LRU List Checkpoint
InnoDB要保證LRU列表中有100左右空閑頁可使用。在InnoDB1.1.X版本前，要檢查LRU中是否有足夠的頁用于用戶查詢操作線程，如果沒有，會將LRU列表尾端的頁淘汰，如果被淘汰的頁中有臟頁，會強制執行Checkpoint刷回臟頁數據到磁盤，顯然這會阻塞用戶查詢線程。從InnoDB1.2.X版本開始，這個檢查放到單獨的Page
Cleaner Thread中進行，并且用戶可以通過innodb_lru_scan_depth控制LRU列表中可用頁的數量，默認值為1024。
Async/Sync Flush Checkpoint
是指重做日志文件不可用時，需要強制將臟頁列表中的一些頁刷新回磁盤。這可以保證重做日志文件可循環使用。在InnoDB1.2.X版本之前，Async
Flush Checkpoint會阻塞發現問題的用戶查詢線程，Sync Flush
Checkpoint會阻塞所有查詢線程。InnoDB1.2.X之后放到單獨的Page Cleaner Thread。
Dirty Page Too Much Checkpoint
臟頁數量太多時，InnoDB引擎會強制進行Checkpoint。目的還是為了保證緩沖池中有足夠可用的空閑頁。其可以通過參數innodb_max_dirty_pages_pct來設置，默認為75%。
Innodb的事務日志是指Redo log，簡稱Log,保存在日志文件ib_logfile*里面。Innodb還有另外一個日志Undo log，但Undo log是存放在共享表空間里面的（ibdata*文件）。
由于Log和Checkpoint緊密相關，因此將這兩部分合在一起分析。
名詞解釋：LSN，日志序列號，Innodb的日志序列號是一個64位的整型。
Log寫入LSN實際上對應日志文件的偏移量，新的LSN＝舊的LSN + 寫入的日志大小。舉例如下：
LSN＝1G，日志文件大小總共為600M，本次寫入512字節，則實際寫入操作為：
| --- 求出偏移量：由于LSN數值遠大于日志文件大小，因此通過取余方式，得到偏移量為400M；
| --- 寫入日志：找到偏移400M的位置，寫入512字節日志內容，下一個事務的LSN就是1000000512；
Checkpoint寫入
Innodb實現了Fuzzy Checkpoint的機制，每次取到最老的臟頁，然后確保此臟頁對應的LSN之前的LSN都已經寫入日志文件，再將此臟頁的LSN作為Checkpoint點記錄到日志文件，意思就是“此LSN之前的LSN對應的日志和數據都已經寫入磁盤文件”。恢復數據文件的時候，Innodb掃描日志文件，當發現LSN小于Checkpoint對應的LSN，就認為恢復已經完成。
Checkpoint寫入的位置在日志文件開頭固定的偏移量處，即每次寫Checkpoint都覆蓋之前的Checkpoint信息。
由于Checkpoint和日志緊密相關，將日志和Checkpoint一起說明，詳細的實現機制如下：
如上圖所示，Innodb的一條事務日志共經歷4個階段：
1） 創建階段：事務創建一條日志；
2） 日志刷盤：日志寫入到磁盤上的日志文件；
3） 數據刷盤：日志對應的臟頁數據寫入到磁盤上的數據文件；
4） 寫CKP：日志被當作Checkpoint寫入日志文件；
對應這4個階段，系統記錄了4個日志相關的信息，用于其它各種處理使用：
Log sequence number（LSN1）：當前系統LSN最大值，新的事務日志LSN將在此基礎上生成（LSN1+新日志的大小）；
Log flushed up to（LSN2）：當前已經寫入日志文件的LSN；
Pages flushed up to（LSN3）：當前最舊的臟頁數據對應的LSN，寫Checkpoint的時候直接將此LSN寫入到日志文件；
Last checkpoint at（LSN4）：當前已經寫入Checkpoint的LSN；
對于系統來說，以上4個LSN是遞減的，即： LSN1>=LSN2>=LSN3>=LSN4.
具體的樣例如下（使用show engine innodb status \G命令查看）
當事務執行速度大于臟頁刷盤速度時，Ckp age和Buf age會逐步增長，當達到async點的時候，強制進行臟頁刷盤或者寫Checkpoint，如果這樣做還是趕不上事務執行的速度，則為了避免數據丟失，到達sync點的時候，會阻塞其它所有的事務，專門進行臟頁刷盤或者寫Checkpoint。
因此從理論上來說,只要事務執行速度大于臟頁刷盤速度，最終都會觸發日志保護機制，進而將事務阻塞，導致MySQL操作掛起。
由于寫Checkpoint本身的操作相比寫臟頁要簡單，耗費時間也要少得多，且Ckp sync點在Buf sync點之后，因此絕大部分的阻塞都是阻塞在了Buf sync點，這也是當事務阻塞的時候，IO很高的原因，因為這個時候在不斷的刷臟頁數據到磁盤。例如如下截圖的日志顯示了很多事務阻塞在了Buf sync點：
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
