Jak naprawić błąd MySQL 1064?

Błąd MySQL 1064 — dokładny komunikat: 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 nie może przeanalizować przesłanego kodu SQL. Fragment pokazany w cudzysłowie wskazuje dokładnie miejsce, w którym analiza się zatrzymała — zacznij diagnozę właśnie tam.

Błąd MySQL 1064 to błąd składni: MySQL otrzymał instrukcję SQL, której nie potrafił przeanalizować. Komunikat o błędzie zawsze zawiera numer linii oraz fragment zapytania, który wywołał błąd — oba są Twoimi najszybszymi wskazówkami diagnostycznymi. Najczęstsze przyczyny:

1. Nieprawidłowa składnia — literówka, brakujący przecinek lub źle umieszczone słowo kluczowe.
2. Błędy ortograficzne — SLECT zamiast SELECT, WHER zamiast WHERE.
3. Słowa zarezerwowane — używanie order, table lub key jako nazw kolumn lub tabel bez backticków.
4. Niezgodne nawiasy — niezamknięty ( lub nadmiarowy ) w podzapytaniu.
5. Brakujące lub nieprawidłowe dane — zmienna w zapytaniu jest pusta lub zawiera nieoczekiwaną wartość.
6. Przestarzała składnia — polecenia ze starszych wersji MySQL (TYPE=MyISAM, CHARSET=latin1), które zawodzą na nowszych serwerach.

Która przyczyna dotyczy Ciebie?

Skorzystaj z tej tabeli, aby zidentyfikować najbardziej prawdopodobną przyczynę, zanim przejdziesz do rozwiązań:

Rozwiązywanie błędu MySQL 1064

1. Sprawdź dokładnie swoją składnię

Komunikat o błędzie MySQL wskazuje dokładną pozycję znaku, w której zatrzymała się analiza. Przeczytaj fragment podany w cudzysłowie w komunikacie, a następnie przyjrzyj się kodowi SQL bezpośrednio przed tym miejscem. Najczęstsze problemy strukturalne:

• Brakujący przecinek między definicjami kolumn w CREATE TABLE
• Średnik wewnątrz ciała procedury składowanej, który przedwcześnie kończy całą instrukcję
• Słowo kluczowe użyte w niewłaściwej klauzuli (WHERE zamiast HAVING w zapytaniu agregującym)

Przykład przed/po — brakujący przecinek:

-- 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. Zwróć uwagę na nawiasy

Każdy otwierający nawias wymaga odpowiadającego mu nawiasu zamykającego. Podzapytania i klauzule IN (...) to najczęstsze źródło niezbilansowania nawiasów — zwłaszcza podczas ręcznej edycji zapytania lub składania go z części.

Przykład przed/po — niezamknięte podzapytanie:

-- 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. Błędy ortograficzne: Częsty winowajca

MySQL nie próbuje automatycznie poprawiać błędnie napisanego słowa kluczowego — natychmiast przerywa analizę i zwraca błąd 1064. Wystarczy pojedynczy przestawiony znak w SELECT, INSERT, UPDATE, WHERE lub jakimkolwiek innym słowie zarezerwowanym, aby go wywołać.

Przykład przed/po — błędnie napisane SELECT:

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

-- Fixed
SELECT id, name FROM users;

Solidny SQL Syntax Checker wychwytuje te literówki, zanim uruchomisz zapytanie na działającej bazie danych.

Tutaj identyfikuje błąd i wskazuje linię zawierającą błąd.

4. Prawidłowo escapuj słowa zarezerwowane

MySQL rezerwuje pewne słowa na potrzeby własnej składni: ORDER, TABLE, KEY, INDEX, DATABASE, SELECT, FROM, WHERE oraz wiele innych. Użycie któregokolwiek z nich jako nazwy tabeli lub kolumny bez backticków powoduje błąd 1064. Rozwiązaniem jest umieszczenie identyfikatora w backtickach.

Przykład przed/po — słowo zarezerwowane jako nazwa tabeli:

-- 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` (...

Różne wersje MySQL mają różne listy słów zarezerwowanych. Podczas migracji bazy danych ze starszej wersji MySQL słowo, które było bezpieczne w MySQL 5.7, może być zarezerwowane w MySQL 8.0. Sprawdź MySQL Reference Manual dla swojej wersji docelowej i wykonaj operację znajdź-i-zamień na zrzucie przed importem.

5. Radzenie sobie z brakującymi danymi

Jeśli zmienna PHP, która zasila zapytanie SQL, jest pusta lub nieustawiona, złożony kod SQL staje się nieprawidłowy. Zapytanie takie jak WHERE id = (bez niczego po =) jest poprawną konkatenacją łańcuchów w PHP, ale nieprawidłowym kodem SQL.

Przykład przed/po — pusta zmienna:

// $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";

Zweryfikuj zmienną przed zbudowaniem zapytania:

// 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);

Aby zdiagnozować to w działającym środowisku WordPress, otwórz phpMyAdmin lub Adminer, przejdź do panelu zapytań SQL i uruchom zapytanie ze znaną, poprawną wartością literałową, aby potwierdzić, że składnia jest poprawna w izolacji. Jeśli tam przejdzie, problem tkwi w sposobie wypełniania zmiennej, a nie w samej strukturze zapytania.

6. Aktualizacja przestarzałych poleceń

Składnia MySQL zmienia się między głównymi wersjami. Zrzuty baz danych wygenerowane w MySQL 5.x często zawierają składnię, która natychmiast zawodzi na serwerach MySQL 8.x. Dwie najczęstsze przyczyny w migracjach witryn WordPress:

TYPE=MyISAM (usunięte; użyj 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 w rygorystycznym MySQL 8:

Starsze zrzuty określają CHARSET=latin1. W MySQL 8.0 z character_set_server=utf8mb4 i sql_mode=STRICT_TRANS_TABLES może to spowodować błąd 1064 w linii CREATE TABLE. Napraw zrzut przed importem:

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

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

Na podstawie zgłoszeń do działu wsparcia WP STAGING, najczęstszym wyzwalaczem błędu 1064 w migracjach WordPress jest stary zrzut zawierający TYPE=MyISAM — zawodzi przy pierwszym CREATE TABLE i przerywa cały import. Operacja znajdź-i-zamień w edytorze tekstu przed uruchomieniem importu rozwiązuje to natychmiast.

Aby potwierdzić wersję MySQL działającą na Twoim serwerze:

SELECT VERSION();

Skorzystaj z MySQL Reference Manual, aby zapoznać się z pełną listą usuniętej i zmienionej składni między wersjami.

Co zrobić, jeśli rozwiązanie nie działa

Jeśli przeszedłeś przez wszystkie sześć przyczyn, a błąd 1064 nadal występuje, skorzystaj z tej listy kontrolnej, aby wyizolować przyczynę źródłową:

1. Upewnij się, że masz połączenie z właściwą bazą danych. Uruchom SHOW TABLES;, aby sprawdzić, że tabela, do której kierujesz zapytanie, istnieje i nazywa się dokładnie tak, jak oczekuje tego zapytanie — wraz z prefiksem tabel WordPress.
2. Zweryfikuj swoją wersję MySQL:Jeśli składnia zapytania wymaga nowszej wersji MySQL niż zainstalowana, zaktualizuj MySQL lub przepisz zapytanie pod zainstalowaną wersję.
3. Sprawdź prefiks tabel WordPress. Tabele WordPress używają prefiksu zdefiniowanego w wp-config.php (zwykle wp_). Zapytanie, które na stałe wpisuje wp_options, zawodzi, jeśli rzeczywisty prefiks to wpstg_ lub inny.
4. Wyizoluj klauzulę powodującą błąd. Uprość zapytanie do najprostszej postaci — usuwaj złączenia, podzapytania i klauzule WHERE pojedynczo, aż błąd 1064 zniknie. Ostatnia usunięta klauzula jest przyczyną.
5. Włącz rejestrowanie debugowania WordPress. Jeśli błąd 1064 pochodzi z wtyczki lub motywu, włączenie WP_DEBUG i WP_DEBUG_LOG przechwytuje pełne zapytanie wraz ze śladem stosu. Zobacz jak włączyć tryb dziennika debugowania WordPress — wpis w dzienniku wskaże dokładną funkcję generującą nieprawidłowe zapytanie.

Podsumowanie

Błąd MySQL 1064 zawsze sprowadza się do jednej konkretnej przyczyny: literówki, słowa zarezerwowanego użytego bez backticków, niezgodności nawiasów, brakującej zmiennej lub przestarzałej składni w zrzucie bazy danych. Komunikat o błędzie MySQL podaje numer linii i dokładny fragment, w którym analiza zawiodła — to jest Twój punkt wyjścia. Zastosuj odpowiednie rozwiązanie powyżej i skorzystaj z listy kontrolnej rozwiązywania problemów, jeśli pierwsza próba tego nie naprawi.

Powiązane artykuły

• 3 sposoby na rozwiązanie błędu składni w WordPressie
• Jak rozwiązać błąd 502 Bad Gateway w WordPressie
• Jak utworzyć i dodać użytkownika administratora z MySQL w WordPressie
• Jak naprawić „Another Update is Currently in Progress” w WordPressie
• 3 sposoby zmiany prefiksu tabeli bazy danych WordPress

Autor: Rene Hermenau

O autorze: René Hermenau jest założycielem WP STAGING. Zajmuje się kopiami zapasowymi WordPressa, środowiskami stagingowymi, migracjami, obsługą baz danych oraz bezpiecznymi procesami wdrażania.

Zobacz pełny profil autora Rene Hermenau