我們知道InnoDB采用Write Ahead Log策略來防止宕機數據丟失，即事務提交時，先寫重做日志，再修改內存數據頁，這樣就產生了臟頁。既然有重做日志保證數據持久性，查詢時也可以直接從緩沖池頁中取數據，那為什么還要刷新臟頁到磁盤呢？如果重做日志可以無限增大，同時緩沖池足夠大，能夠緩存所有數據，那么是不需要將緩沖池中的臟頁刷新到磁盤。但是，通常會有以下幾個問題：
- 服務器內存有限，緩沖池不夠用，無法緩存全部數據
- 重做日志無限增大成本要求太高
- 宕機時如果重做全部日志恢復時間過長
事實上，當數據庫宕機時，數據庫不需要重做所有的日志，只需要執行上次刷入點之后的日志。這個點就叫做Checkpoint，它解決了以上的問題：
- 縮短數據庫恢復時間
- 緩沖池不夠用時，將臟頁刷新到磁盤
- 重做日志不可用時，刷新臟頁
重做日志被設計成可循環使用，當日志文件寫滿時，重做日志中對應數據已經被刷新到磁盤的那部分不再需要的日志可以被覆蓋重用。
InnoDB引擎通過LSN(Log Sequence Number)來標記版本，LSN是日志空間中每條日志的結束點，用字節偏移量來表示。每個page有LSN，redo log也有LSN，Checkpoint也有LSN。可以通過命令show engine innodb status來觀察：
--- LOG --- Log sequence number 11102619599 Log flushed up to 11102618636 Last checkpoint at 11102606319 0 pending log writes, 0 pending chkp writes 15416290 log i/o's done, 12.32 log i/o's/second
Checkpoint機制每次刷新多少頁，從哪里取臟頁，什么時間觸發刷新？這些都是很復雜的。有兩種Checkpoint，分別為：
- Sharp Checkpoint
- Fuzzy Checkpoint
Sharp Checkpoint發生在關閉數據庫時，將所有臟頁刷回磁盤。在運行時使用Fuzzy Checkpoint進行部分臟頁的刷新。部分臟頁刷新有以下幾種：
- Master Thread Checkpoint
- FLUSH_LRU_LIST Checkpoint
- Async/Sync Flush Checkpoint
- Dirty Page too much Checkpoint
Master Thread Checkpoint
Master Thread以每秒或每十秒的速度從緩沖池的臟頁列表中刷新一定比例的頁回磁盤。這個過程是異步的，不會阻塞查詢線程。
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來設置：
mysql> show variables like 'innodb_max_dirty_pages_pct'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | innodb_max_dirty_pages_pct | 90 | +----------------------------+-------+