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

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

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

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