2026年7月4日

WordPressのDBで壊れたテーブルをREPAIR TABLEで修復する手順（InnoDBの場合の対処も）

データベース・バックアップ

「Table is marked as crashed and should be repaired」のようなエラーが出たら、REPAIR TABLE で直せるのは MyISAM（MariaDB では Aria も）のテーブルです。現在の WordPress で主流の InnoDB は REPAIR TABLE に対応しておらず、別の手順が必要になります。この記事では、エラーの読み方からストレージエンジンの確認、MyISAM と InnoDB それぞれの修復手順、再発防止までを順に説明します。

作業の前に：バックアップとディスク容量

修復作業はデータファイルを書き換えます。失敗すると状態が悪化することもあるため、最初に現状を保存してください。

mysqldump やホスティングのバックアップ機能でダンプを取る: 壊れたテーブルでダンプが止まる場合は、そのテーブルを除外して他を先に保存します。
可能ならデータディレクトリごとコピーする: VPS なら MySQL / MariaDB を停止して、データディレクトリ（例: /var/lib/mysql）を丸ごと複製しておくと、作業前の状態に戻せます。
ディスクの空き容量を確認する: df -h で確認します。容量不足はテーブル破損の原因にもなり、修復処理そのものも一時ファイルを作るため、空きがないと失敗します。

エラーメッセージから状況を読む

WordPress の画面には「データベース接続確立エラー」や「データベースの修復が必要」とだけ出ることがあります。詳しい内容は PHP のエラーログや MySQL のエラーログに残ります。よく見るメッセージと意味は次のとおりです。

Table './dbname/wp_options' is marked as crashed and should be repaired（エラー145）: MyISAM のテーブルが不正終了などで「壊れている」印を付けられた状態です。REPAIR TABLE の対象です。
Incorrect key file for table（エラー126）: インデックスファイルの不整合です。一時ディレクトリの容量不足でも出るため、まずディスク容量を確認します。
The storage engine for the table doesn't support repair: InnoDB のテーブルに REPAIR TABLE を実行したときの応答です。壊れているという意味ではありません。
MySQL が起動しない／起動直後に落ち、エラーログに InnoDB の破損に関する記述がある: InnoDB 側の破損です。後述の手順を使います。

原因として多いもの（可能性の高い順）

サーバーの不正終了: 停電、OOM Killer によるプロセス強制終了、強制再起動。MyISAM は書き込み途中で止まると壊れやすい構造です。確認はエラーログとシステムログ（dmesg や journalctl）で行います。
ディスク容量不足: 書き込みが途中で失敗します。df -h で確認し、不要なログやバックアップを移して空きを作ります。
古いテーブルが MyISAM のまま: 長く運用しているサイトや、MyISAM を既定にしていた頃に作られたプラグインのテーブルが残っているケースです。
ストレージやハードウェアの障害: 頻度は低いものの、InnoDB の破損はこれが原因のことがあります。修復より先にサーバー会社への連絡やディスク診断が必要です。

どのテーブルが、どのエンジンかを確認する

phpMyAdmin の一覧の「種類」列でも確認できますが、SQL なら次のように調べられます。your_db_name は実際のデータベース名に置き換えてください。

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

-- 破損の有無を調べる（読み取り中心の処理）
CHECK TABLE wp_options, wp_posts, wp_postmeta;

CHECK TABLE の結果の Msg_text が OK 以外ならそのテーブルに問題があります。WP-CLI が使えるなら wp db check で全テーブルをまとめて調べられます（内部で mysqlcheck を呼び出します）。

MyISAM / Aria のテーブルを修復する

REPAIR TABLE を実行する

REPAIR TABLE wp_options;

結果の Msg_text が OK になれば修復は完了です。修復中はテーブルがロックされるため、アクセスの少ない時間に行います。WP-CLI の wp db repair、またはシェルからの mysqlcheck --repair でも同じ処理を複数テーブルにまとめて実行できます。

# 例: データベース全体を修復（ユーザー名・DB名は環境に合わせる）
mysqlcheck -u your_db_user -p --repair your_db_name

通常の REPAIR TABLE で直らない場合に REPAIR TABLE ... EXTENDED や USE_FRM というオプションがあります。USE_FRM はテーブル定義からインデックスを作り直す最後の手段で、状況によってはデータを失うおそれがあります。使う前にデータディレクトリのコピーがあることを確認してください。

WordPress のデータベース修復画面を使う

サーバーのコマンドが使えない場合は、WordPress 標準の修復ページを使えます。wp-config.php の「編集が必要なのはここまで」の行より上に次の1行を追加します。

define( 'WP_ALLOW_REPAIR', true );

そのうえで https://example.com/wp-admin/maint/repair.php にアクセスすると、「データベースを修復」「データベースを修復し最適化」のボタンが表示されます。このページはログインなしで誰でも開けるため、作業が終わったらすぐにこの1行を削除してください。

InnoDB のテーブルが壊れている場合

InnoDB はクラッシュ後に自動で回復処理を行うため、通常は再起動だけで元に戻ります。それでも起動しない、または特定のテーブルを読むと落ちる場合は次の順で進めます。

エラーログを読む: どのテーブル・どのページで問題が起きているかが記録されています。
innodb_force_recovery で起動してデータを取り出す: my.cnf の [mysqld] に innodb_force_recovery = 1 を設定して起動を試し、起動しなければ値を1つずつ上げます。MySQL の公式ドキュメントでは、4以上はデータファイルを恒久的に壊す可能性があるとされています。起動できたら mysqldump でデータを書き出します。この状態は読み出し専用の緊急手段で、通常運用には使いません。
作り直す: 書き出したダンプを、設定を戻した正常なサーバー（新しいデータベース）に読み込みます。
バックアップから戻す方が早いことも多い: 直前のバックアップがあり、それ以降の更新が少ないなら、修復を粘るより復元する方が安全です。

レンタルサーバーで my.cnf を触れない場合は、サーバー会社のサポートに相談するか、管理画面のバックアップ復元機能を使います。

修復後にやること

MyISAM を InnoDB へ変換する: クラッシュに強い InnoDB へ移しておくと再発しにくくなります。ALTER TABLE wp_options ENGINE=InnoDB; のように1テーブルずつ実行します。全文検索インデックスなど MyISAM 固有の機能を使っているプラグインのテーブルは、対応を確認してから変換してください。
サイトの表示と管理画面を確認する: 設定値（wp_options）が欠けていると、テーマやプラグインの設定が初期化されて見えることがあります。
定期バックアップを見直す: 毎日の自動バックアップと、別の場所への保管があるかを確認します。修復できない破損の最終手段はバックアップからの復元です。
不正終了の原因を取り除く: メモリ不足でプロセスが落ちているなら、PHP-FPM のプロセス数や MySQL のメモリ設定を見直します。

ホスティングによって phpMyAdmin のメニュー表記や修復機能の有無は異なります（2026年10月現在）。

まとめ

REPAIR TABLE は MyISAM / Aria 用。InnoDB では「対応していない」と返るのが正常な応答
作業前にダンプとデータディレクトリのコピーを取り、ディスク容量を確認する
MyISAM は REPAIR TABLE、mysqlcheck --repair、wp db repair、WP_ALLOW_REPAIR の修復画面で直す。修復画面は使用後すぐ無効化する
InnoDB はエラーログを読み、innodb_force_recovery は1から順に上げてデータを取り出す。バックアップからの復元も検討する
修復後は InnoDB への変換と、バックアップ体制の見直しで再発を防ぐ