SQLite Prepared Statements: prepare, bind, step, finalize

Was ein Prepared Statement wirklich ist

Wenn du SQLite einen SQL-String übergibst, muss erst einiges an Vorarbeit passieren, bevor auch nur eine einzige Zeile bewegt wird: Der String wird tokenisiert, geparst, es wird geprüft, ob Tabellen und Spalten existieren, ein Ausführungsplan wird erstellt und schließlich in Bytecode für die virtuelle Maschine von SQLite kompiliert. Erst danach läuft die Abfrage wirklich los.

Ein Prepared Statement ist das, was du erhältst, wenn du genau bei „in Bytecode kompiliert" stehen bleibst und dir dieses Ergebnis aufhebst. Das kompilierte Programm hat Lücken — Platzhalter —, die später mit den eigentlichen Werten gefüllt werden. Dasselbe kompilierte Programm kannst du beliebig oft mit unterschiedlichen Werten ausführen, und zwar auch dann sicher, wenn die Werte aus unsicheren Quellen stammen.

Stell es dir wie den Unterschied vor, ob du jemandem jedes Mal beim Kochen das Rezept laut vorliest, oder ob du ihm das Rezept einmal beibringst und am Tag selbst nur noch die Zutaten nennst.

Der Lebenszyklus: prepare, bind, step, finalize

Jeder SQLite-Treiber in jeder Sprache kapselt dieselben vier Aufrufe der C-API. Die Namen zu kennen hilft, selbst wenn du niemals C schreiben wirst — Fehlermeldungen und Dokus benutzen genau dieses Vokabular:

1. sqlite3_prepare_v2 — kompiliert einen SQL-String zu einem Statement-Handle.
2. sqlite3_bind_* — befüllt die Platzhalter mit Werten (eine Funktion pro Datentyp).
3. sqlite3_step — führt das Programm aus. Bei SELECT rufst du es wiederholt auf, um durch die Zeilen zu laufen. Bei INSERT/UPDATE/DELETE reicht ein einziger Aufruf.
4. sqlite3_finalize — gibt das kompilierte Programm wieder frei, sobald du fertig bist.

Zwischendurch spult sqlite3_reset ein abgearbeitetes Statement zurück, sodass du es neu binden und erneut ausführen kannst, ohne es noch einmal zu präparieren.

Platzhalter im SQL

Im SQL-String markierst du jede Stelle, an der ein Wert eingesetzt werden soll, mit einem Platzhalter, statt den Wert direkt in den String hineinzubasteln. SQLite kennt dafür mehrere Schreibweisen:

-- Anonym, positionsbasiert:
INSERT INTO users (name, email) VALUES (?, ?);

-- Nummeriert:
INSERT INTO users (name, email) VALUES (?1, ?2);

-- Benannt:
INSERT INTO users (name, email) VALUES (:name, :email);
INSERT INTO users (name, email) VALUES (@name, @email);
INSERT INTO users (name, email) VALUES ($name, $email);

? ist in Treiber-Code am gebräuchlichsten. Benannte Platzhalter (:name) lesen sich angenehmer, wenn du mehrere Parameter hast oder denselben Wert mehrfach brauchst. Entscheide dich pro Projekt für einen Stil und bleib dabei.

Was du auf keinen Fall tun solltest: das Query per String-Konkatenation zusammenbauen:

-- DAS NICHT TUN:
"INSERT INTO users (name) VALUES ('" + user_input + "')"

Das ist die direkte Einladung für SQL-Injection – und es macht außerdem genau die Bytecode-Wiederverwendung kaputt, um die es gleich gehen wird.

Ein Praxisbeispiel direkt in SQL

Damit du die Mechanik hinter Prepare/Bind/Step auch ohne Host-Sprache nachvollziehen kannst, hier das Ganze nur mit Bordmitteln von SQLite. Wir legen eine Tabelle an und fügen eine Zeile ein – mit einem Platzhalter im Stil einer parameterisierten Abfrage, der durch ein Literal befüllt wird:

CREATE TABLE users (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE
);

INSERT INTO users (name, email) VALUES ('Ada', 'ada@example.com');
INSERT INTO users (name, email) VALUES ('Boris', 'boris@example.com');

SELECT id, name, email FROM users ORDER BY id;

In einer echten Anwendung würdest du die Werte natürlich nicht direkt in den SQL-String schreiben. Stattdessen bereitest du das INSERT einmal mit ?, ? als Platzhaltern via prepare vor, bindest dann pro Nutzer das Name/E-Mail-Paar mit bind und führst es mit step aus. Der kompilierte Bytecode bleibt bei jedem Aufruf identisch – nur die gebundenen Werte ändern sich.

Prepared Statements wiederverwenden (der Performance-Gewinn)

Genau dieses Muster nimmt dir dein SQLite-Treiber ab. Hier als Pseudocode – jede Sprache schreibt es ein wenig anders, aber die Struktur ist überall gleich:

-- einmalig vorbereitet:
INSERT INTO users (name, email) VALUES (?, ?);

-- dann in einer Schleife:
--   bind(1, name)
--   bind(2, email)
--   step()
--   reset()

Vorbereiten, einmal kompilieren – dann ausführen

Beim Vorbereiten wird das SQL einmalig geparst und kompiliert. Jede Iteration führt anschließend nur noch den Bytecode aus und kopiert Werte in vorbereitete Slots. Bei Massen-Inserts (denk an einen Import von 100.000 Zeilen) ist das dramatisch schneller, als 100.000 einzeln geparste Statements abzusetzen – oft um eine Größenordnung, vor allem wenn das Ganze in einer einzigen Transaktion läuft.

Ein typischer Stolperstein: Man baut eine Schleife und ruft prepare innerhalb der Schleife auf. Damit ist der gesamte Vorteil dahin. Faustregel: prepare außerhalb der Schleife, bind und step innerhalb.

Warum das der sichere Weg ist

Gebundene Parameter sind keine Strings, die ins SQL eingesetzt werden. Es sind Werte, die dem Bytecode-Programm über typisierte Slots übergeben werden – Integer-Slots, Text-Slots, Blob-Slots. SQLite parst sie niemals erneut als SQL, daher kann kein übergebener Wert jemals die Struktur der Abfrage verändern. So lassen sich SQL-Injections von vornherein ausschließen.

Zum Vergleich:

-- Verwundbar. Wenn user_input lautet:  '); DROP TABLE users;--
-- wird die Abfrage zerstörerisch.
"SELECT * FROM users WHERE name = '" + user_input + "'"

-- Sicher. user_input wird als TEXT-Wert gebunden und immer nur
-- als Zeichenkette verglichen, egal was darin enthalten ist.
SELECT * FROM users WHERE name = ?;

Die zweite Variante bleibt selbst dann sicher, wenn user_input den Wert '); DROP TABLE users;-- hat. SQLite sucht brav nach einem Nutzer, dessen Name exakt diesem (reichlich seltsamen) String entspricht, findet keinen Treffer und liefert null Zeilen zurück. Die Struktur der Abfrage lässt sich durch den Wert schlicht nicht verändern.

SQL Injection schauen wir uns in einem späteren Kapitel noch genauer an, aber die Quintessenz lautet: Prepared Statements sind nicht einfach eine Möglichkeit, SQL Injection zu vermeiden — sie sind die Möglichkeit.

Statements, die Zeilen zurückgeben

Bei einem SELECT liefert step jeweils eine Zeile pro Aufruf. Der Treiber durchläuft üblicherweise eine Schleife, bis "done" zurückkommt:

CREATE TABLE products (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    price REAL NOT NULL
);

INSERT INTO products (name, price) VALUES
    ('Notizbuch', 4.50),
    ('Stift',     1.20),
    ('Radiergummi', 0.80);

SELECT name, price FROM products WHERE price < 2.00 ORDER BY price;

In echtem Anwendungscode würde der Treiber dieses SELECT mit einem ? anstelle von 2.00 vorbereiten (prepare), den Schwellwert binden und dann in einer Schleife step aufrufen, wobei pro Aufruf eine Zeile gelesen wird. Nach der letzten Zeile meldet step das Ende, und der Treiber führt entweder ein reset auf dem Statement aus (um es mit einem neuen Schwellwert erneut laufen zu lassen) oder ruft finalize auf.

Finalize nicht vergessen

Ein Prepared Statement ist eine kleine Allokation innerhalb von SQLite. Wenn man sie leckt, frisst das Speicher – und, was schwerer wiegt, es hält einen internen Lock auf der Datenbank, der andere Schreibvorgänge blockieren kann. Jeder Treiber bietet einen Weg, automatisch aufzuräumen – Context Manager in Python, using-Blöcke in C#, RAII in C++ – und genau die solltest du nutzen:

• Pythons sqlite3 finalisiert beim Garbage-Collecten des Cursors, aber ein explizites cursor.close() ist sauberer.
• better-sqlite3 (Node) finalisiert, wenn das Statement vom Garbage Collector erfasst wird; langlebige Prepared Statements sind völlig in Ordnung.
• In reinem C rufst du sqlite3_finalize selbst auf. Es zu vergessen ist ein echter Bug.

Die Faustregel: Wenn du es vorbereitet hast, muss irgendetwas es auch finalisieren.

Wann du es selbst gar nicht brauchst

In der Praxis wirst du sqlite3_prepare_v2 nur selten direkt aufrufen. High-Level-Treiber machen aus connection.execute("SELECT ... WHERE id = ?", (42,)) automatisch prepare/bind/step/finalize. Der Lebenszyklus ist trotzdem wichtig zu verstehen, weil:

• Du erkennst, was passiert, wenn du Fehler wie "statement is busy" oder "cannot operate on a finalized statement" siehst.
• Du weißt, dass du langlebige Prepared Statements cachen solltest, wenn du in einer engen Schleife INSERTs machst.
• Du schreibst parametrisierte Abfragen ganz automatisch, auch wenn String-Konkatenation gerade verlockend aussieht.

ORMs und Query Builder gehen noch einen Schritt weiter. Sie bauen das SQL, verwalten die Prepared Statements und liefern dir typisierte Ergebnisse zurück. Darunter liegen aber immer dieselben vier Aufrufe.

Als Nächstes: Parameter binden

Bisher haben wir nur abstrakt über Platzhalter gesprochen. Im nächsten Schritt schauen wir uns das Binden im Detail an – positionsbasierte vs. benannte Parameter, Typumwandlung, NULL und die kleinen Stolpersteine, die auftauchen, sobald du anfängst, echte Anwendungsdaten in Queries zu schicken.