MySQL 1064 Error: 解決方法は？

MySQL 1064エラー — 正確なメッセージ: 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は送信されたSQLを解析できません。引用符で示されたフラグメントは、解析が停止した正確な位置を示しています。診断はそこから始めてください。

MySQL 1064エラーは構文エラーです。MySQLが解析できないSQL文を受け取ったときに発生します。エラーメッセージには常に、失敗を引き起こした行番号とクエリのフラグメントが含まれており、どちらも最も迅速な診断の手がかりとなります。よくある原因は次のとおりです:

不正な構文 — タイプミス、欠落したカンマ、または誤った位置のキーワード。
スペルミス — SELECTの代わりにSLECT、WHEREの代わりにWHER。
予約語 — order、table、keyをバッククォートなしでカラム名やテーブル名として使用すること。
対応していない括弧 — サブクエリ内で閉じられていない(または余分な)。
不足または不正なデータ — クエリ内の変数が空であるか、予期しない値を含んでいる。
時代遅れの構文 — 新しいサーバーで失敗する古いMySQLバージョンのコマンド（TYPE=MyISAM、CHARSET=latin1）。

Contents

どの原因に該当しますか？
MySQL 1064エラーの解決
修正がうまくいかない場合の対処法
まとめ
関連記事

どの原因に該当しますか？

修正に取り掛かる前に、この表を使用して最も可能性の高い原因を特定してください:

症状	最も可能性の高い原因	修正
エラーメッセージが問題の単語としてSQLキーワード（`ORDER`、`KEY`、`TABLE`、`INDEX`、`DATABASE`）を示している	バッククォートなしでカラム名やテーブル名として使用された予約語	修正4: 予約語をエスケープする
エラーが`(`または`)`付近の行番号を指している	括弧の不一致	修正2: 括弧を確認する
データベースダンプのインポートまたはMySQLのアップグレード後にエラーが発生した	ダンプ内の時代遅れの構文（`TYPE=MyISAM`、`CHARSET=latin1`）	修正6: 時代遅れのコマンドを更新する
以前は動作していた動的クエリが現在は失敗する。クエリにPHP変数が含まれている	空または欠落した変数の値	修正5: 不足データへの対処
問題のトークンがスペルミスのキーワード（`SLECT`、`INSRET`、`WHER`）	スペルミス	修正3: スペルを修正する
上記のいずれにも該当しない — クエリ構造の一般的な問題	クエリ構造の構文の問題	修正1: 構文を確認する

MySQL 1064エラーの解決

1. 構文を再確認する

MySQLのエラーメッセージは、解析が停止した正確な文字位置を示します。エラー内の引用されたフラグメントを読み、その直前のSQLを確認してください。最もよくある構造的な問題は次のとおりです:

CREATE TABLEのカラム定義間のカンマの欠落
ストアドプロシージャ本体内のセミコロンが文全体を途中で終了させてしまう
誤った句で使用されたキーワード（集計クエリでHAVINGの代わりにWHERE）

修正前/修正後の例 — カンマの欠落:

-- 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. 括弧に注意を払う

開き括弧にはそれぞれ対応する閉じ括弧が必要です。サブクエリとIN (...)句は、括弧の不均衡の最もよくある原因です。特にクエリを手作業で編集したり、部分から組み立てたりする場合に発生します。

修正前/修正後の例 — 閉じられていないサブクエリ:

-- 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. スペルミス: よくある原因

MySQLはスペルミスのキーワードを自動修正しようとしません。すぐに解析を停止し、1064エラーを返します。SELECT、INSERT、UPDATE、WHERE、その他の予約語の文字が1つでも入れ替わると、これが発生します。

修正前/修正後の例 — スペルミスのSELECT:

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

-- Fixed
SELECT id, name FROM users;

堅牢なSQL Syntax Checkerは、本番データベースに対してクエリを実行する前にこれらのタイプミスを検出します。

ここでは、エラーを特定し、エラーを含む行を指定します。

4. 予約語を適切にエスケープする

MySQLは、独自の構文のために特定の単語を予約しています：ORDER、TABLE、KEY、INDEX、DATABASE、SELECT、FROM、WHERE、その他多数。これらのいずれかをバッククォートなしでテーブル名やカラム名として使用すると、1064エラーが発生します。修正方法は、識別子をバッククォートで囲むことです。

修正前/修正後の例 — テーブル名としての予約語:

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

SQL

CREATE TABLE `order` (...

MySQLのバージョンによって予約語のリストは異なります。古いMySQLバージョンからデータベースを移行する場合、MySQL 5.7では安全だった単語がMySQL 8.0では予約語になっている可能性があります。対象バージョンのMySQL Reference Manualを確認し、インポートする前にダンプに対して検索置換を実行してください。

5. 不足データへの対処

SQLクエリに渡されるPHP変数が空または未設定の場合、組み立てられたSQLは不正な形式になります。WHERE id = （=の後に何もない）のようなクエリは、有効なPHP文字列連結ですが、無効なSQLです。

修正前/修正後の例 — 空の変数:

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

クエリを構築する前に変数を検証してください:

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

本番のWordPress環境でこれを診断するには、phpMyAdminまたはAdminerを開き、SQLクエリパネルに移動し、既知の正しいリテラル値でクエリを実行して、構文が単独で正しいことを確認します。そこで成功した場合、問題はクエリ構造自体ではなく、変数の設定方法にあります。

6. 時代遅れのコマンドのアップグレード

MySQLの構文はメジャーバージョン間で変化します。MySQL 5.xで生成されたデータベースダンプには、MySQL 8.xサーバーで即座に失敗する構文がしばしば含まれています。WordPressサイト移行における最もよくある2つの原因は次のとおりです:

TYPE=MyISAM（削除済み。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;

厳格なMySQL 8でのDEFAULT CHARSET=latin1:

古いダンプはCHARSET=latin1を指定しています。character_set_server=utf8mb4とsql_mode=STRICT_TRANS_TABLESが設定されたMySQL 8.0では、CREATE TABLE行で1064エラーが発生する可能性があります。インポートする前にダンプを修正してください:

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

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

WP STAGINGのサポートチケットによると、WordPress移行における最もよくある1064の原因は、TYPE=MyISAMを含む古いダンプです。最初のCREATE TABLEで失敗し、インポート全体が中止されます。インポートを実行する前にテキストエディタで検索置換を行うことで、すぐに解決します。

サーバーで実行されているMySQLのバージョンを確認するには:

SELECT VERSION();

バージョン間で削除・変更された構文の完全なリストについては、MySQL Reference Manualを参照してください。

修正がうまくいかない場合の対処法

6つの原因すべてに取り組んでも1064エラーが解消されない場合は、このチェックリストを使用して根本原因を特定してください:

正しいデータベースに接続していることを確認してください。 SHOW TABLES;を実行して、クエリ対象のテーブルが存在し、WordPressのテーブルプレフィックスを含めてクエリが期待するとおりの名前であることを確認します。
MySQLのバージョンを確認してください:クエリの構文がインストールされているものより新しいMySQLバージョンを必要とする場合は、MySQLをアップグレードするか、インストールされているバージョン用にクエリを書き直してください。
WordPressのテーブルプレフィックスを確認してください。 WordPressのテーブルはwp-config.phpで定義されたプレフィックス（一般的にはwp_）を使用します。wp_optionsをハードコードしたクエリは、実際のプレフィックスがwpstg_などの場合に失敗します。
失敗している句を切り分けてください。 クエリを最もシンプルな形に削ぎ落とします。1064エラーが消えるまで、結合、サブクエリ、WHERE句を1つずつ削除していきます。最後に削除した句が原因です。
WordPressのデバッグログを有効にしてください。 1064エラーがプラグインやテーマに起因する場合、WP_DEBUGとWP_DEBUG_LOGを有効にすると、スタックトレースとともに完全なクエリがキャプチャされます。WordPressのデバッグログモードを有効にする方法を参照してください。ログエントリには、不正な形式のクエリを生成している正確な関数が記録されます。

まとめ

MySQL 1064エラーは常に、1つの特定の原因にたどり着きます。タイプミス、バッククォートなしで使用された予約語、括弧の不一致、欠落した変数、またはデータベースダンプ内の時代遅れの構文です。MySQLのエラーメッセージは、解析が失敗した行番号と正確なフラグメントを示します。それが出発点です。上記の該当する修正を適用し、最初の試みで解決しない場合はトラブルシューティングのチェックリストを使用してください。

著者： Rene Hermenau

著者について: René Hermenau は WP STAGING の創設者です。WordPress のバックアップ、ステージング、移行、データベース処理、安全なデプロイメントワークフローに取り組んでいます。

Rene Hermenauの著者プロフィール全文を見る