In Datenbankanwendungen kommt es häufig vor, dass ein Primärschlüssel ein eindeutiger Identifier ist und neue Zeilen in der aufsteigenden Reihenfolge des Primärschlüssels eingefügt werden. So sind für Einfügungen in den geclusterten Index keine willkürlichen Lesezugriffe auf eine Festplatte erforderlich.

Dagegen sind Sekundärindizes normalerweise nicht-eindeutig und Einfügungen in sie finden in relativ willkürlicher Reihenfolge statt. Dies würde eine Menge willkürlicher E/A-Operationen auf der Festplatte erfordern, wenn es in InnoDB nicht einen speziellen Mechanismus gäbe.

Wenn ein Indexeintrag in einen nicht-eindeutigen Sekundärindex eingefügt werden soll, prüft InnoDB, ob dieser Sekundärindex im Bufferpool liegt. Wenn ja, führt InnoDB die Einfügung direkt auf der Indexseite durch. Wenn nicht, fügt InnoDB den Eintrag in eine spezielle Insert-Puffer-Struktur ein. Der Insert-Puffer wird so klein gehalten, dass er komplett in den Bufferpool passt und Einfügungen sehr schnell erledigt werden können.

Dieser Insert-Puffer wird regelmäßig mit den Sekundärindexbäumen in der Datenbank zusammengeführt. Oft können mehrere Einfügeoperationen auf derselben Seite des Indexbaums gleichzeitig zusammengeführt werden, was Festplattenzugriffe spart. Messungen haben ergeben, dass der Insert-Puffer Einfügungen in eine Tabelle bis zu 15-mal schneller laufen lässt.

Das Zusammenführen von Insert-Puffer-Daten kann auch dann weitergehen, nachdem die einfügende Transaktion committet wurde, ja sogar nach dem Herunterfahren und Neustart des Servers (siehe Abschnitt 14.2.8.1, „Erzwingen einer InnoDB-Wiederherstellung (Recovery)“).

Das Zusammenführen von Insert-Puffer-Daten kann viele Stunden dauern, wenn viele Sekundärindizes aktualisiert werden müssen und viele Zeilen eingefügt wurden. In dieser Zeit erhöht sich die E/A-Aktivität, sodass festplattengebundene Anfragen eventuell viel langsamer laufen. Eine andere, wichtige E/A-Hintergrundoperation ist der Purge-Thread (siehe Abschnitt 14.2.12, „Implementierung der Multiversionierung“).