InnoDB implementiert einen „fuzzy“ Checkpoint-Mechanismus. InnoDB schreibt Datenbankseiten, die geändert wurden, in kleinen Batches aus dem Bufferpool auf die Platte. Es ist nicht nötig, den Bufferpool in einem einzigen, großen Batch auf die Platte zu schreiben, da dies in der Praxis dazu führen würde, dass Benutzer während des Checkpointing-Prozesses keine SQL-Anweisungen erteilen können.

Bei einer Recovery sucht InnoDB ein Checkpoint-Label in den Logdateien, da es weiß, dass alle Datenbankmodifikationen, die diesem Label vorausgingen, im Disk-Image der Datenbank vorhanden sind. Dann scannt InnoDB die Logdateien von dem Checkpoint aus nach vorne durch und wendet die dort protokollierten Modifikationen auf die Datenbank an.

InnoDB schreibt Daten in rotierender Weise in seine Logdateien. Alle committeten Modifikationen, die dazu führen, dass Datenbankseiten im Bufferpool von den Images auf der Festplatte abweichen, müssen in den Logdateien vorhanden sein, falls InnoDB einmal eine Recovery durchführen muss. Wenn InnoDB eine Logdatei benutzt, muss es also dafür sorgen, dass die Datenbankseiten-Images auf der Platte die in der für die Recovery verwendeten Logdatei protokollierten Modifikationen enthalten. Mit anderen Worten muss InnoDB einen Checkpoint anlegen, wozu häufig modifizierte Datenbankseiten auf die Platte zurückgeschrieben werden müssen.

Dies erklärt auch, warum sehr große Logdateien die Plattenzugriffe beim Checkpointing reduzieren. Oft ist es sinnvoll, die Gesamtgröße der Logdateien auf die Größe des Bufferpools oder sogar einen noch höheren Wert einzustellen. Der Nachteil großer Logdateien: Die Recovery kann dann länger dauern, da mehr Informationen in die Datenbank eingebracht werden müssen.