WordPressのデータベーステーブルが壊れたときの修復手順｜確認・修復・復元の判断

WordPress のデータベースのテーブルが壊れると、サイトが表示されない、管理画面に入れない、記事や設定の一部が消えたように見える、といった症状が出ます。対処は「バックアップを取る → どのテーブルが壊れているかを調べる → テーブルの種類（ストレージエンジン）に合った方法で直す → 直らなければバックアップから戻す」の順で進めます。この記事では、その全体の流れと判断のしかたを説明します（2026年10月時点の WordPress のソースコードと MySQL / MariaDB の公式ドキュメントに基づきます）。

症状とエラーメッセージ

テーブルの破損が疑われる表示には、次のようなものがあります。

• 「データベース接続確立エラー」（Error establishing a database connection）: 接続情報の誤りや MySQL の停止でも出るため、これだけでは破損と決められません。まず MySQL / MariaDB が動いているか、wp-config.php の接続情報が正しいかを確認します。
• 「One or more database tables are unavailable. The database may need to be repaired.」（日本語表示では、データベースのテーブルが利用できず修復が必要かもしれない、という趣旨のメッセージ）: WordPress の基本テーブルの一部が読めないときに出ます。
• PHP や MySQL のエラーログに「Table '...' is marked as crashed and should be repaired」: MyISAM のテーブルが壊れた印を付けられた状態です。
• 「Incorrect key file for table」: インデックスの不整合です。一時領域のディスク容量不足でも出ます。
• MySQL が起動しない、または起動直後に落ち、エラーログに InnoDB の記述がある: InnoDB 側の問題です。

原因として多いのは、停電や強制再起動・メモリ不足によるプロセスの強制終了などの不正終了と、ディスク容量の不足です。

作業の前にバックアップを取る

修復はデータファイルを書き換えます。結果が悪化したときに戻れるよう、最初に現状を保存します。

# データベース全体をダンプする（ユーザー名・DB名は環境に合わせる）
mysqldump -u wp_user -p --single-transaction wordpress_db > before-repair.sql

# 壊れたテーブルでダンプが止まる場合は、そのテーブルを除いて先に保存する
mysqldump -u wp_user -p --single-transaction --ignore-table=wordpress_db.wp_options wordpress_db > before-repair-partial.sql

# ディスクの空き容量を確認する
df -h

MariaDB では mysqldump の代わりに mariadb-dump という名前の場合があります。VPS などで管理者権限があるなら、MySQL / MariaDB を止めてデータディレクトリ（例: /var/lib/mysql）を丸ごとコピーしておくと、作業前の状態に戻せます。ディスクがいっぱいなら、修復より先に不要なファイルを移して空きを作ります。

どのテーブルが壊れているかを調べる

ストレージエンジンを確認する

修復方法はテーブルの種類で変わるため、まずエンジンを確認します。wordpress_db は実際のデータベース名に置き換えます。

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

現在の WordPress のテーブルは通常 InnoDB です。古くから運用しているサイトや、古いプラグインが作ったテーブルには MyISAM が残っていることがあります。

CHECK TABLE で調べる

CHECK TABLE wp_options, wp_posts, wp_postmeta;

結果の Msg_text が OK 以外のテーブルに問題があります。データベース全体をまとめて調べるなら、WP-CLI の wp db check、またはシェルから mysqlcheck を使います。

# WP-CLI（wp-config.php の接続情報で mysqlcheck --check を実行する）
wp db check

# mysqlcheck を直接使う場合
mysqlcheck -u wp_user -p --check wordpress_db

修復方法の選び方

InnoDB のテーブルに REPAIR TABLE を実行すると「The storage engine for the table doesn't support repair」と返ります。これは「壊れている」という意味ではなく、このエンジンでは使えないという応答です。

MyISAM のテーブルを修復する

SQL で直接修復する場合は次のとおりです。

REPAIR TABLE wp_options;

Msg_text が OK になれば修復できています。複数のテーブルをまとめて修復するなら、WP-CLI かシェルを使います。

# WP-CLI（内部で mysqlcheck --repair を実行する）
wp db repair

# mysqlcheck を直接使う場合
mysqlcheck -u wp_user -p --repair wordpress_db

修復後は、同じテーブルを InnoDB に変換しておくと、不正終了で壊れにくくなります。

ALTER TABLE wp_options ENGINE=InnoDB;

WordPress の修復画面を使う

SSH やデータベースの管理画面が使えない場合は、WordPress に付属する修復画面を使えます。wp-config.php の「編集が必要なのはここまで」の行より上に次の1行を追加します。

define( 'WP_ALLOW_REPAIR', true );

そのうえで https://example.com/wp-admin/maint/repair.php を開き、「データベースを修復」または「データベースを修復し最適化」を選びます。この画面は、テーブルごとに CHECK TABLE を実行し、OK でなかったテーブルにだけ REPAIR TABLE を実行します。「修復し最適化」を選ぶと、問題が無かった場合に ANALYZE TABLE と OPTIMIZE TABLE も実行します。

知っておきたい点が2つあります。

• 対象は WordPress 本体のテーブルだけ: プラグインが作った独自のテーブルは、既定では対象になりません。対象に加えるには tables_to_repair フィルターを使います（下の例）。
• ログインなしで誰でも開ける: 作業が終わったら、すぐに wp-config.php から WP_ALLOW_REPAIR の行を削除します。

プラグインのテーブルも修復画面の対象にしたい場合は、たとえば wp-content/mu-plugins/repair-extra-tables.php として次のファイルを置きます。テーブル名は実際のものに置き換えてください。作業が終わったら、このファイルも削除します。

<?php
// WordPress の修復画面（repair.php）の対象にプラグインのテーブルを加える
add_filter( 'tables_to_repair', function ( $tables ) {
	global $wpdb;
	$tables[] = $wpdb->prefix . 'myplugin_logs';
	return $tables;
} );

InnoDB のテーブルでは、この画面でも REPAIR TABLE は効きません。

InnoDB のテーブルに問題がある場合

InnoDB は、不正終了の後に起動するとログを使って自動で回復します。まずは MySQL / MariaDB を再起動し、エラーログを確認します。

テーブルは読めるものの CHECK TABLE でエラーが出る場合は、テーブルを作り直します。

-- テーブルを作り直す（データを読み直して新しく書き込む）
ALTER TABLE wp_posts ENGINE=InnoDB;

テーブルが読めない、または MySQL が起動しない場合は、次の順で考えます。

1. 直前のバックアップがあり、その後の更新が少ないなら、バックアップから戻す: 多くの場合、これがいちばん早く安全です。
2. バックアップが無い、または古すぎる場合は、innodb_force_recovery でデータを取り出す: 設定ファイル（my.cnf など）の [mysqld] に innodb_force_recovery = 1 を書いて起動を試し、起動できなければ値を1つずつ上げます。MySQL の公式ドキュメントでは、4以上はデータファイルを恒久的に壊すおそれがあるとされています。起動できたら mysqldump でデータを書き出し、設定を戻した正常なデータベースに読み込みます。
3. ストレージの障害が疑われる場合: 同じディスクでの作業を続けず、サーバー会社への連絡やディスクの診断を先に行います。

innodb_force_recovery を付けた状態は、データを取り出すための緊急手段です。そのまま通常運用には使いません。共用のレンタルサーバーでは設定ファイルを変更できないため、サーバー会社の管理画面のバックアップ機能で戻すか、サポートに相談します。

バックアップから戻す

修復で直らない場合や、修復しても記事や設定が欠けている場合は、壊れる前のバックアップから戻します。戻す前に、今の状態もダンプしておきます（戻した後に、バックアップ以降の記事を手で移すときに使います）。

# 現在の状態を保存してから、バックアップを読み込む
wp db export now-broken.sql
wp db import backup-20261029.sql

wp db import は既存のテーブルを上書きします。WP-CLI が使えない場合は、mysql -u wp_user -p wordpress_db < backup-20261029.sql でも読み込めます。

修復した後に確認すること

• サイトと管理画面の表示: トップページ、記事ページ、ログイン、プラグインの設定画面を確認します。wp_options が欠けていると、テーマやプラグインの設定が初期状態に戻って見えることがあります。
• もう一度 CHECK TABLE: wp db check で全テーブルが OK になったかを確かめます。
• 原因を取り除く: ディスク容量の監視、メモリ不足でのプロセス強制終了の有無（dmesg や journalctl で確認）を見直します。
• 定期バックアップの確認: 毎日の自動バックアップと、サーバー外への保管ができているかを確かめます。

まとめ

• 「データベース接続確立エラー」は破損以外でも出る。エラーログで原因を絞り込む
• 作業前にダンプを取り、ディスクの空きを確認する
• エンジンを確認し、CHECK TABLE や wp db check で壊れたテーブルを特定する
• MyISAM は REPAIR TABLE・wp db repair・修復画面で直す。修復画面は本体のテーブルだけが対象で、使い終わったら WP_ALLOW_REPAIR を消す
• InnoDB は REPAIR TABLE が使えない。再起動・作り直し・バックアップからの復元・innodb_force_recovery の順に検討する

関連記事:

• WordPressのDBで壊れたテーブルをREPAIR TABLEで修復する手順
• WP-CLIでWordPressのデータベースを修復する方法
• InnoDBとMyISAMの違い