InnoDB は 「fuzzy」 チェックポイントとして知られているチェックポイント性能を実装します。InnoDB は小さいバッチ内のバッファープールから変更されたデータベースページをフラッシュします。チェックポイント処理の最中にユーザー SQL ステートメントの処理を実際に停止させる、バッファープールを単一バッチ内でフラッシュする必要はありません。

クラッシュ復旧の最中に、InnoDB はログファイルに書き込まれたチェックポイントラベルを探します。それは、ラベルの前のデータベースへのすべての変更がデータベースのディスクイメージ内に存在することを知っています。そして、InnoDB はデータベースにログされた変更を適用しながら、チェックポイントから前方にログファイルを走査します。

InnoDB は交代制でそのログファイルに書き込みをします。バッファープール内のデータベースページがディスク上のイメージと異なるようにコミットされたすべての変更は、InnoDB が復旧を行わなければいけない場合のためにログファイル内で有効である必要があります。これは、InnoDB がログファイルを再利用し始めたとき、ディスク上のデータベースのイメージが、InnoDB が再利用しようとしているログファイル内にログされた変更を確実に含むということを意味します。言い換えると、InnoDB はチェックポイントを作成する必要があり、変更されたデータベースページをディスクにフラッシュすることを含んでいることが多いです。

前出の説明の中で、なぜログファイルをとても大きくすることがチェックポイントの中でディスク I/O が減るかも知れないのかが説明されています。ログファイル全体の大きさをバッファープールと同じ、またはそれよりも大きく設定することは意味を持つことが多いです。大きいログファイルを利用することの欠点は、データベースに適用させるログ情報がより多くあるために、クラッシュ復旧に長時間かかるということです。