Wie behebt man den MySQL 1064 Error?

MySQL 1064-Fehler — exakte Meldung: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '...' at line N

MySQL kann das von Ihnen übermittelte SQL nicht parsen. Das in Anführungszeichen angezeigte Fragment markiert genau die Stelle, an der das Parsen gestoppt wurde — beginnen Sie Ihre Diagnose dort.

Der MySQL 1064-Fehler ist ein Syntaxfehler: MySQL hat eine SQL-Anweisung erhalten, die es nicht parsen konnte. Die Fehlermeldung enthält immer die Zeilennummer und das Abfragefragment, das den Fehler ausgelöst hat — beide sind Ihre schnellsten diagnostischen Hinweise. Häufige Ursachen:

1. Falsche Syntax — ein Tippfehler, ein fehlendes Komma oder ein falsch platziertes Schlüsselwort.
2. Rechtschreibfehler — SLECT statt SELECT, WHER statt WHERE.
3. Reservierte Wörter — die Verwendung von order, table oder key als Spalten- oder Tabellennamen ohne Backticks.
4. Nicht zusammenpassende Klammern — ein nicht geschlossenes ( oder ein überflüssiges ) in einer Unterabfrage.
5. Fehlende oder fehlerhafte Daten — eine Variable in der Abfrage ist leer oder enthält einen unerwarteten Wert.
6. Veraltete Syntax — Befehle aus älteren MySQL-Versionen (TYPE=MyISAM, CHARSET=latin1), die auf neueren Servern fehlschlagen.

Welche Ursache habe ich?

Verwenden Sie diese Tabelle, um die wahrscheinlichste Ursache zu identifizieren, bevor Sie sich den Lösungen widmen:

Den MySQL 1064-Fehler beheben

1. Überprüfen Sie Ihre Syntax doppelt

Die Fehlermeldung von MySQL nennt Ihnen die exakte Zeichenposition, an der das Parsen gestoppt wurde. Lesen Sie das in Anführungszeichen genannte Fragment in der Fehlermeldung und sehen Sie sich dann das SQL unmittelbar vor dieser Stelle an. Die häufigsten strukturellen Probleme:

• Fehlendes Komma zwischen Spaltendefinitionen in CREATE TABLE
• Ein Semikolon innerhalb des Rumpfes einer Stored Procedure, das die gesamte Anweisung vorzeitig beendet
• Ein Schlüsselwort, das in der falschen Klausel verwendet wird (WHERE statt HAVING bei einer Aggregatabfrage)

Vorher/Nachher-Beispiel — fehlendes Komma:

-- Broken: no comma after the first column definition
CREATE TABLE users (
    id INT NOT NULL
    username VARCHAR(50)
);

-- Fixed
CREATE TABLE users (
    id INT NOT NULL,
    username VARCHAR(50)
);

2. Achten Sie auf Klammern

Jede öffnende Klammer benötigt eine passende schließende Klammer. Unterabfragen und IN (...)-Klauseln sind die häufigste Quelle für ein Klammer-Ungleichgewicht — besonders, wenn Sie eine Abfrage von Hand bearbeiten oder aus Teilen zusammensetzen.

Vorher/Nachher-Beispiel — nicht geschlossene Unterabfrage:

-- Broken: missing closing ) for the IN subquery
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
;

-- Fixed
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
);

3. Rechtschreibfehler: Ein häufiger Übeltäter

MySQL versucht nicht, ein falsch geschriebenes Schlüsselwort automatisch zu korrigieren — es stoppt das Parsen sofort und gibt einen 1064-Fehler zurück. Ein einziges vertauschtes Zeichen in SELECT, INSERT, UPDATE, WHERE oder einem anderen reservierten Wort löst dies aus.

Vorher/Nachher-Beispiel — falsch geschriebenes SELECT:

-- Broken
SLECT id, name FROM users;
-- Error: ... near 'SLECT id, name FROM users'

-- Fixed
SELECT id, name FROM users;

Ein robuster SQL Syntax Checker erkennt diese Tippfehler, bevor Sie die Abfrage gegen eine Live-Datenbank ausführen.

Hier identifiziert er den Fehler und gibt die Zeile an, in der sich der Fehler befindet.

4. Reservierte Wörter ordnungsgemäß escapen

MySQL reserviert bestimmte Wörter für seine eigene Syntax: ORDER, TABLE, KEY, INDEX, DATABASE, SELECT, FROM, WHERE und viele weitere. Die Verwendung eines dieser Wörter als Tabellen- oder Spaltenname ohne Backticks verursacht einen 1064-Fehler. Die Lösung besteht darin, den Bezeichner in Backticks einzuschließen.

Vorher/Nachher-Beispiel — reserviertes Wort als Tabellenname:

-- Broken: ORDER is a MySQL reserved word
SELECT name FROM order WHERE id = 1;
-- Error: ... near 'order WHERE id = 1'

-- Fixed: backticks tell MySQL this is an identifier, not a keyword
SELECT name FROM `order` WHERE id = 1;

CREATE TABLE `order` (...

Verschiedene MySQL-Versionen haben unterschiedliche Listen reservierter Wörter. Beim Migrieren einer Datenbank von einer älteren MySQL-Version kann ein Wort, das in MySQL 5.7 unbedenklich war, in MySQL 8.0 reserviert sein. Konsultieren Sie das MySQL Reference Manual für Ihre Zielversion und führen Sie vor dem Import ein Suchen-und-Ersetzen im Dump durch.

5. Fehlende Daten beheben

Wenn eine PHP-Variable, die in eine SQL-Abfrage einfließt, leer oder nicht gesetzt ist, wird das zusammengesetzte SQL fehlerhaft. Eine Abfrage wie WHERE id = (mit nichts nach dem =) ist gültige PHP-String-Verkettung, aber ungültiges SQL.

Vorher/Nachher-Beispiel — leere Variable:

// $orderId is empty — the POST field was not submitted
$orderId = $_POST['order_id'] ?? '';

// Resulting SQL is broken:
// SELECT * FROM orders WHERE id =
$sql = "SELECT * FROM orders WHERE id = $orderId";

Validieren Sie die Variable, bevor Sie die Abfrage erstellen:

// Fixed: validate before use
if (empty($orderId) || !is_numeric($orderId)) {
    return; // do not run a malformed query
}
$sql = "SELECT * FROM orders WHERE id = " . intval($orderId);

Um dies in einer Live-WordPress-Umgebung zu diagnostizieren, öffnen Sie phpMyAdmin oder Adminer, navigieren Sie zum SQL-Abfragefeld und führen Sie die Abfrage mit einem bekannt gültigen literalen Wert aus, um zu bestätigen, dass die Syntax isoliert betrachtet korrekt ist. Wenn sie dort durchläuft, liegt das Problem darin, wie die Variable befüllt wird, und nicht in der Abfragestruktur selbst.

6. Veraltete Befehle aktualisieren

Die MySQL-Syntax ändert sich zwischen Hauptversionen. Datenbank-Dumps, die auf MySQL 5.x erstellt wurden, enthalten häufig Syntax, die auf MySQL-8.x-Servern sofort fehlschlägt. Die beiden häufigsten Ursachen bei WordPress-Website-Migrationen:

TYPE=MyISAM (entfernt; verwenden Sie ENGINE=InnoDB):

-- Broken on MySQL 5.5+ (TYPE= keyword was removed)
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) TYPE=MyISAM;

-- Fixed
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) ENGINE=InnoDB;

DEFAULT CHARSET=latin1 bei striktem MySQL 8:

Ältere Dumps geben CHARSET=latin1 an. Auf MySQL 8.0 mit character_set_server=utf8mb4 und sql_mode=STRICT_TRANS_TABLES kann dies einen 1064-Fehler in der CREATE TABLE-Zeile verursachen. Korrigieren Sie den Dump vor dem Import:

-- Find in the dump file:
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Replace with:
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Aus den Support-Tickets von WP STAGING ist der häufigste 1064-Auslöser bei WordPress-Migrationen ein alter Dump, der TYPE=MyISAM enthält — er schlägt beim ersten CREATE TABLE fehl und bricht den gesamten Import ab. Ein Suchen-und-Ersetzen in einem Texteditor vor dem Ausführen des Imports behebt dies sofort.

Um die MySQL-Version zu bestätigen, die auf Ihrem Server läuft:

SELECT VERSION();

Konsultieren Sie das MySQL Reference Manual für eine vollständige Liste der zwischen den Versionen entfernten und geänderten Syntax.

Was tun, wenn die Lösung nicht funktioniert

Wenn Sie alle sechs Ursachen durchgearbeitet haben und der 1064-Fehler weiterhin besteht, verwenden Sie diese Checkliste, um die eigentliche Ursache einzugrenzen:

1. Stellen Sie sicher, dass Sie mit der richtigen Datenbank verbunden sind. Führen Sie SHOW TABLES; aus, um zu überprüfen, dass die abgefragte Tabelle existiert und exakt so heißt, wie Ihre Abfrage es erwartet — einschließlich des WordPress-Tabellenpräfixes.
2. Überprüfen Sie Ihre MySQL-Version:Wenn die Abfragesyntax eine neuere MySQL-Version erfordert als die installierte, aktualisieren Sie MySQL oder schreiben Sie die Abfrage für die installierte Version um.
3. Prüfen Sie das WordPress-Tabellenpräfix. WordPress-Tabellen verwenden das in wp-config.php definierte Präfix (üblicherweise wp_). Eine Abfrage, die wp_options fest verdrahtet, schlägt fehl, wenn das tatsächliche Präfix wpstg_ oder etwas anderes ist.
4. Grenzen Sie die fehlerhafte Klausel ein. Reduzieren Sie die Abfrage auf ihre einfachste Form — entfernen Sie Joins, Unterabfragen und WHERE-Klauseln nacheinander, bis der 1064-Fehler verschwindet. Die zuletzt entfernte Klausel ist die Ursache.
5. Aktivieren Sie das WordPress-Debug-Logging. Wenn der 1064-Fehler von einem Plugin oder Theme stammt, erfasst das Aktivieren von WP_DEBUG und WP_DEBUG_LOG die vollständige Abfrage mit ihrem Stack-Trace. Siehe wie Sie den WordPress-Debug-Log-Modus aktivieren — der Log-Eintrag nennt die genaue Funktion, die die fehlerhafte Abfrage erzeugt.

Fazit

Der MySQL 1064-Fehler lässt sich immer auf eine konkrete Ursache zurückführen: einen Tippfehler, ein ohne Backticks verwendetes reserviertes Wort, nicht zusammenpassende Klammern, eine fehlende Variable oder veraltete Syntax in einem Datenbank-Dump. Die Fehlermeldung von MySQL nennt Ihnen die Zeilennummer und das genaue Fragment, an dem das Parsen fehlgeschlagen ist — das ist Ihr Ausgangspunkt. Wenden Sie die passende Lösung oben an und nutzen Sie die Checkliste zur Fehlerbehebung, falls der erste Versuch das Problem nicht behebt.

Verwandte Artikel

• 3 Wege zur Behebung von Syntaxfehlern in WordPress
• So beheben Sie den Fehler 502 Bad Gateway in WordPress
• So erstellen und fuegen Sie einen Admin-Benutzer mit MySQL in WordPress hinzu
• So beheben Sie „Another Update is Currently in Progress“ in WordPress
• 3 Wege, das WordPress-Datenbanktabellenpraefix zu aendern

Autor: Rene Hermenau

Über den Autor: René Hermenau ist Gründer von WP STAGING. Er arbeitet an WordPress-Backups, Staging, Migrationen, Datenbankverarbeitung und sicheren Deployment-Workflows.

Vollständiges Autorenprofil von Rene Hermenau ansehen