InnoDB的Checkpoint技術(shù)是什么？這個問題可能是我們?nèi)粘W(xué)習(xí)或工作經(jīng)常見到的。希望通過這個問題能讓你收獲頗深。下面是小編給大家?guī)淼膮⒖純?nèi)容，讓我們一起來看看吧！

站在用戶的角度思考問題，與客戶深入溝通，找到沂源網(wǎng)站設(shè)計與沂源網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、申請域名、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋沂源地區(qū)。

一句話概括，Checkpoint技術(shù)就是將緩存池中臟頁在某個時間點刷回到磁盤的操作

遇到的問題 ？

都知道緩沖池的出現(xiàn)就是為了解決CPU與磁盤速度之間的鴻溝，免得我們在讀寫數(shù)據(jù)庫時還需要進行磁盤IO操作。有了緩沖池后，所有的頁操作首先都是在緩沖池內(nèi)完成的。

如一個DML語句，進行數(shù)據(jù)update或delete 操作時，此時改變了緩沖池頁中的記錄，此時因為緩沖池頁的數(shù)據(jù)比磁盤的新，此時的頁就叫做臟頁。

不管怎樣，總會后的內(nèi)存頁數(shù)據(jù)需要刷回到磁盤里，這里就涉及幾個問題：

• 若每次一個頁發(fā)生變化，就將新頁的版本刷新到磁盤，那么這個開銷是非常大的
• 若熱點數(shù)據(jù)集中在某幾個頁中，那么數(shù)據(jù)庫的性能將變得非常差
• 如果在從緩沖池將頁的新版本刷新到磁盤時發(fā)生了宕機，那么數(shù)據(jù)就不能恢復(fù)了

Write Ahead Log（預(yù)寫式日志）

WAL策略解決了刷新頁數(shù)據(jù)到磁盤時發(fā)生宕機而導(dǎo)致數(shù)據(jù)丟失的問題，它是關(guān)系數(shù)據(jù)庫系統(tǒng)中用于提供原子性和持久性（ACID 屬性中的兩個）的一系列技術(shù)。

WAL策略核心點就是

redo log，每當(dāng)有事務(wù)提交時，先寫入 redo log（重做日志），在修改緩沖池數(shù)據(jù)頁，這樣當(dāng)發(fā)生掉電之類的情況時系統(tǒng)可以在重啟后繼續(xù)操作

WAL策略機制原理

InnoDB為了保證數(shù)據(jù)不丟失，維護了redo log。在緩沖池的數(shù)據(jù)頁修改之前，需要先將修改的內(nèi)容記錄到redo log中，并保證redo log早于對應(yīng)的數(shù)據(jù)頁落盤，這就是WAL策略。

當(dāng)故障發(fā)生而導(dǎo)致內(nèi)存數(shù)據(jù)丟失后，InnoDB會在重啟時，通過重放redo log，將緩沖池數(shù)據(jù)頁恢復(fù)到崩潰前的狀態(tài)。

Checkpoint

按理說有了WAL策略，我們就可以高枕無憂了。但其問題點又出現(xiàn)在redo log上面：

• redo log 不可能是無限大的，不能沒完沒了的存儲我們的數(shù)據(jù)等待一起刷新到磁盤
• 在數(shù)據(jù)庫怠機恢復(fù)時，如果redo log 太大的話恢復(fù)的代價也是非常大的

所以為了解決臟頁的刷新性能，臟頁應(yīng)該在什么時間、什么情況下進行臟頁的刷新就用到了Checkpoint技術(shù)。

Checkpoint 的目的

1、縮短數(shù)據(jù)庫的恢復(fù)時間

當(dāng)數(shù)據(jù)庫怠機恢復(fù)時，不需要重做所有的日志信息。因為Checkpoint前的數(shù)據(jù)頁已經(jīng)刷回到磁盤了。只需要Checkpoint后的redo log進行恢復(fù)就好了。

2、緩沖池不夠用時，將臟頁刷新到磁盤

當(dāng)緩沖池空間不足時，根據(jù)LRU算法會溢出最近最少使用的頁，若此頁為臟頁，那么需要強制執(zhí)行Checkpoint，將臟頁也就是頁的新版本刷回磁盤。

3、redo log不可用時，刷新臟頁

如圖redo log 的不可用是因為當(dāng)前數(shù)據(jù)庫對其設(shè)計都是循環(huán)使用的，所以其空間并不是無限大。

當(dāng)redo log被寫滿, 因為此時系統(tǒng)不能接受更新, 所有更新語句都會被堵住。

此時必須強制產(chǎn)生Checkpoint需要將 write pos 向前推進，推進范圍內(nèi)的臟頁都需要刷新到磁盤

Checkpoint 的種類

Checkpoint發(fā)生的時間、條件及臟頁的選擇等都非常復(fù)雜。

Checkpoint 每次刷新多少臟頁到磁盤？

Checkpoint每次從哪里取臟頁？

Checkpoint 什么時間被觸發(fā)？

面對上面的問題，InnoDB存儲引擎內(nèi)部為我們提供了兩種Checkpoint：

• Sharp Checkpoint

  發(fā)生在數(shù)據(jù)庫關(guān)閉時將所有的臟頁都刷新回磁盤，這是默認(rèn)的工作方式，參數(shù)innodb_fast_shutdown=1

• Fuzzy Checkpoint

  InnoDB存儲引擎內(nèi)部使用這種模式,只刷新一部分臟頁，而不是刷新所有的臟頁回磁盤

FuzzyCheckpoint發(fā)生的情況

• Master Thread Checkpoint

  差不多以每秒或每十秒的速度從緩沖池的臟頁列表中刷新一定比例的頁回磁盤。

  這個過程是異步的，即此時InnoDB存儲引擎可以進行其他的操作，用戶查詢線程不會阻塞

• FLUSH_LRU_LIST Checkpoint

  因為LRU列表要保證一定數(shù)量的空閑頁可被使用，所以如果不夠會從尾部移除頁，如果移除的頁有臟頁，就會進行此Checkpoint。

  5.6版本后，這個Checkpoint放在了一個單獨的Page Cleaner線程中進行，并且用戶可以通過參數(shù)innodb_lru_scan_depth控制LRU列表中可用頁的數(shù)量，該值默認(rèn)為1024

• Async/Sync Flush Checkpoint

  指的是redo log文件不可用的情況，這時需要強制將一些頁刷新回磁盤，而此時臟頁是從臟頁列表中選取的

  5.6版本后不會阻塞用戶查詢

• Dirty Page too much Checkpoint 即臟頁的數(shù)量太多，導(dǎo)致InnoDB存儲引擎強制進行Checkpoint。

  其目的總的來說還是為了保證緩沖池中有足夠可用的頁。

  其可由參數(shù)innodb_max_dirty_pages_pct控制,比如該值為75，表示當(dāng)緩沖池中臟頁占據(jù)75%時，強制進行CheckPoint

總結(jié)

• 因為CPU和磁盤間的鴻溝的問題，從而出現(xiàn)緩沖池數(shù)據(jù)頁來加快數(shù)據(jù)庫DML操作

• 因為緩沖池數(shù)據(jù)頁與磁盤數(shù)據(jù)一致性的問題，從而出現(xiàn)WAL策略（核心就是redo log）

• 因為緩沖池臟頁的刷新性能問題，從而出現(xiàn)Checkpoint技術(shù)

InnoDB 為了提高執(zhí)行效率，并不會每次DML操作都和磁盤交互進行持久化。而是通過Write Ahead Log 先策略寫入redo log保證事物的持久化。

對于事物中修改的緩沖池臟頁，會通過異步的方式刷盤，而內(nèi)存空閑頁和redo log的可用是通過Checkpoint技術(shù)來保證的。

感謝各位的閱讀！看完上述內(nèi)容，你們對InnoDB的Checkpoint技術(shù)是什么大概了解了嗎？希望文章內(nèi)容對大家有所幫助。如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。