1000 Inserts in SQLite – mit einer Transaktion plötzlich 100× schneller

Ich nutze SQLite in fast jedem Projekt. Der häufigste Anfängerfehler beim Import vieler Zeilen: jeden INSERT einzeln abschicken. SQLite macht dann aus jedem Insert eine eigene Transaktion und schreibt sie einzeln sicher auf die Platte (fsync). Das ist langsam – bei tausenden Zeilen dauert es gefühlt ewig.

Langsam: jeder Insert einzeln

-- Ohne Transaktion: 1000× auf die Platte schreiben → zäh
INSERT INTO log (msg) VALUES ('Zeile 1');
INSERT INTO log (msg) VALUES ('Zeile 2');
-- … 998 weitere …

Schnell: alles in eine Transaktion

BEGIN;
INSERT INTO log (msg) VALUES ('Zeile 1');
INSERT INTO log (msg) VALUES ('Zeile 2');
-- … 998 weitere …
COMMIT;

Jetzt wird einmal am Ende sicher geschrieben statt tausendmal. In der Praxis sind das schnell zwei Größenordnungen Unterschied.

Der zweite Gewinn ist Atomarität: Läuft irgendwo mittendrin ein Fehler, brichst du mit ROLLBACK; ab – dann ist keine der Zeilen drin. Du hast nie einen halben, kaputten Import.

In PHP (PDO) sieht das so aus

$db->beginTransaction();
try {
    $stmt = $db->prepare('INSERT INTO log (msg) VALUES (?)');
    foreach ($zeilen as $z) {
        $stmt->execute([$z]);   // dasselbe Prepared Statement wiederverwenden
    }
    $db->commit();
} catch (\Throwable $e) {
    $db->rollBack();            // alles zurück – kein halber Import
    throw $e;
}

Faustregel: Sobald du mehr als eine Handvoll Schreibvorgänge zusammen hast, gehören sie in eine Transaktion. Prepared Statement einmal vorbereiten, in der Schleife nur noch execute – das ist der schnellste und sauberste Weg.

Solche Datenbank-Kniffe stecken in jedem Projekt, das ich baue. Wenn du eine Anwendung mit sauberem, schnellem SQLite-Unterbau brauchst, meld dich gern über bymw.de.

Quellen

• BEGIN/COMMIT — sqlite.org
• FAQ: Warum sind Inserts ohne Transaktion langsam? — sqlite.org