WordPressのデータベースエラーを修復する方法（接続エラー・テーブル破損・InnoDB）

WordPress のデータベースのエラーは、大きく分けて「データベースにつながらない」ものと、「つながるがテーブルに問題がある」ものがあります。原因によって対処がまったく違うので、まずどちらなのかを見分けます。この記事の内容は、2026年11月時点で、WordPress 6.9 のソースコードと MySQL 8.4 の公式マニュアルで確認しています。

修復の操作はデータを書き換えます。作業の前に、取れる範囲でバックアップを取ってください（MySQL の公式マニュアルも、REPAIR TABLE の前にバックアップを取るよう書いています）。

# WP-CLI が使える場合
wp db export ~/backup-before-repair.sql

# mysqldump の場合（-p を付けるとパスワードを聞かれる）
mysqldump -u wp_user -p wp_database > ~/backup-before-repair.sql

コマンドラインにパスワードを直接書くと、シェルの履歴やプロセスの一覧に残るので、-p だけを付けて入力します。

ステップ1：接続エラーの原因を調べる

「データベース接続確立エラー」は、WordPress が wp-config.php の情報でデータベースにつなげなかったときに出ます。上から順に確かめます。

1. 接続情報を確かめる

wp-config.php の次の4つが、実際のデータベースと一致しているかを見ます。

<?php
define( 'DB_NAME', 'wp_database' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'パスワード' );
define( 'DB_HOST', 'localhost' );

レンタルサーバーでは、DB_HOST が localhost ではなく、サーバー会社が指定するホスト名（mysqlXXX.example.ne.jp のような形）の場合があります。サーバーの管理画面に表示される値と比べてください。データベースのパスワードを管理画面で変えたあとに、wp-config.php を直し忘れているのもよくある原因です。

2. 同じ情報でコマンドラインから接続してみる

mysql -u wp_user -p -h localhost wp_database -e 'SELECT 1;'

Access denied ならユーザー名・パスワード・権限の問題（MySQLのAccess deniedエラーの直し方）、Can't connect なら MySQL が止まっているかホスト名の誤りです。DB_HOST が localhost の場合、PHP も mysql コマンドも UNIX ソケットで接続し、127.0.0.1 の場合は TCP で接続します。片方だけ失敗する場合は、ソケットのパスや MySQL の待ち受け設定を確かめます。

SSH が使えず PHP で確かめる場合は、次のファイルを公開ディレクトリの外に置いて、php test-db.php のようにコマンドラインで実行します。Web から開ける場所に置くと、接続情報が漏れるおそれがあります。PHP 8.1 以降の mysqli は、接続に失敗すると例外を投げるので、try／catch で受けます。

<?php
// test-db.php（確認が終わったら消す）
try {
	$conn = new mysqli( 'localhost', 'wp_user', 'パスワード', 'wp_database' );
	echo 'OK: ', $conn->server_info, PHP_EOL;
	$conn->close();
} catch ( mysqli_sql_exception $e ) {
	echo 'NG: ', $e->getMessage(), PHP_EOL;
}

3. MySQL／MariaDB が動いているかを確かめる（VPS・専用サーバー）

systemctl status mysql      # MySQL（Ubuntu／Debian）
systemctl status mariadb    # MariaDB
systemctl status mysqld     # MySQL（RHEL 系）

# 止まっていた理由をログで見る
sudo journalctl -u mysql -n 50 --no-pager
sudo tail -n 50 /var/log/mysql/error.log

# ディスクの空き
df -h

止まっていれば起動し、起動しない場合はログの内容で判断します。メモリ不足で強制終了されている場合（ログに Out of memory や oom-kill がある）は、MySQL の設定やほかのプロセスのメモリの使い方を見直します。ログに InnoDB の破損が記録されている場合はステップ6へ進みます。

接続数の上限（Too many connections）に達している場合は、アクセスの急増やボットの影響も疑います。

ステップ2：テーブルのストレージエンジンを確かめる

修復の方法は、テーブルのストレージエンジンによって違います。WordPress はテーブルを作るときにエンジンを指定せず、MySQL 5.5 以降の既定は InnoDB なので、今のサイトのテーブルは通常 InnoDB です。古いサイトでは MyISAM のテーブルが残っていることがあります。

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'wp_database';

MySQL の公式マニュアルでも、REPAIR TABLE が使えるのは MyISAM・ARCHIVE・CSV のテーブルとされています。2つのエンジンの違いは InnoDBとMyISAMの違い を参照してください。

ステップ3：WordPress の修復ページを使う

WordPress には、テーブルを調べて修復するページ（wp-admin/maint/repair.php）があります。

wp-config.php の「編集が必要なのはここまでです」の行より上に、次の1行を追加します。

<?php
define( 'WP_ALLOW_REPAIR', true );

続けて次のように操作します。

1. ブラウザーで https://example.com/wp-admin/maint/repair.php を開きます。
2. 「データベースを修復」か「データベースを修復し最適化する」を押します。最適化はテーブルをロックし時間がかかることがあるので、まずは修復だけにします。
3. 結果を確認したら、wp-config.php から追加した行をすぐに消します。

このページはログインしなくても開けます。設定を残したままにすると、だれでも修復や最適化を実行できてしまいます。

修復ページは、各テーブルに CHECK TABLE を実行し、問題のあったテーブルにだけ REPAIR TABLE を実行します。InnoDB のテーブルで問題が見つかった場合、REPAIR TABLE では直らないので、修復に失敗したという表示になります。その場合はステップ6を参照してください。

ステップ4：mysqlcheck や SQL で修復する（MyISAM）

WP-CLI が使える場合は次のコマンドで調べ、必要なら修復します。

wp db check     # すべてのテーブルを調べる（mysqlcheck --check と同じ）
wp db repair    # 修復を試みる（mysqlcheck --repair と同じ。InnoDB には効かない）

mysqlcheck を直接使う場合は、まず調べ、壊れていたテーブルだけ自動で修復させます。

# 調べるだけ（既定の動作）
mysqlcheck -u wp_user -p wp_database

# 調べて、壊れていたテーブルだけ修復する
mysqlcheck -u wp_user -p --auto-repair wp_database

phpMyAdmin や mysql コマンドから SQL で行う場合は、テーブルを指定します。

CHECK TABLE wp_posts, wp_postmeta, wp_options;
REPAIR TABLE wp_posts;

Msg_text が OK なら問題はありません。InnoDB のテーブルに REPAIR TABLE を実行すると、エンジンが修復に対応していない旨の表示になります。WP-CLI での手順は WP-CLIでデータベースを修復する方法 も参照してください。

ステップ5：「テーブルが存在しない」と出る場合

まず、wp-config.php のテーブル接頭辞と、データベースにある実際のテーブル名が一致しているかを確かめます。サーバーの移行やバックアップの復元のあとに、接頭辞が食い違うことがあります。

# wp-config.php の接頭辞
wp config get table_prefix

# データベースにあるテーブルをすべて表示する
wp db tables --all-tables

たとえば wp-config.php が wp_ なのに、テーブルが wpabc_posts のようになっていれば、$table_prefix を実際の接頭辞に合わせます。

接頭辞が合っていてもテーブルが無い場合は、テーブルそのものが失われています。バックアップから復元してください。wp core install は新しいサイトを作るコマンドで、失われたデータを戻すことはできません。

ステップ6：InnoDB の破損から復旧する

InnoDB のデータファイルが壊れると、MySQL が起動しなくなったり、特定のテーブルを読むと MySQL が停止したりします。最も確実なのはバックアップからの復元です。バックアップが無い、または新しいデータを取り出したい場合は、innodb_force_recovery で MySQL を起動させてデータを書き出します。

0以外の値では、InnoDB は INSERT・UPDATE・DELETE を受け付けません（4以上は読み取り専用）。WordPress も正常には動かないので、作業中はサイトを止めている前提です。

手順（Ubuntu の例）:

# 1. MySQL を止め、データディレクトリを丸ごとコピーしておく
sudo systemctl stop mysql
sudo cp -a /var/lib/mysql /var/lib/mysql.broken-copy

# 2. 設定ファイルの [mysqld] セクションに innodb_force_recovery = 1 を加える
#    MySQL: /etc/mysql/mysql.conf.d/mysqld.cnf
#    MariaDB: /etc/mysql/mariadb.conf.d/50-server.cnf
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
innodb_force_recovery = 1

# 3. 起動して、データを書き出す
sudo systemctl start mysql
mysqldump -u wp_user -p wp_database > ~/wp_database-recovered.sql

• 起動しない、または書き出しの途中で止まる場合は、値を2、3と1つずつ上げて試します。4以上は、コピーしたデータで試してからにします。
• 書き出せたら、設定ファイルから innodb_force_recovery の行を消して（0に戻して）MySQL を再起動します。
• 新しいデータベースを作って書き出したデータを取り込み（mysql -u ユーザー -p 新しいデータベース名 < ~/wp_database-recovered.sql）、wp-config.php の DB_NAME を新しいデータベースに向けます。元のデータベースは、新しいほうで問題が無いことを確かめるまで消さずに残します。

まとめ

• まず「つながらない」のか「テーブルに問題がある」のかを見分けます。接続エラーは、接続情報、MySQL の状態、ディスクの空きを順に確かめます。
• 修復の前にバックアップを取ります。
• REPAIR TABLE、mysqlcheck の修復、WordPress の修復ページが効くのは MyISAM のテーブルです。WP_ALLOW_REPAIR は使い終わったらすぐ消します。
• 「テーブルが存在しない」は、まず接頭辞の食い違いを疑い、本当に無ければバックアップから戻します。
• InnoDB の破損は、バックアップからの復元か、innodb_force_recovery を1から上げてデータを書き出す方法で対処します。

定期的なバックアップの取り方は データベースのバックアップ を参照してください。