SSHでサーバーに入れる環境なら、WP-CLIを使ってコマンドだけでWordPressのデータベースを点検・修復できます。phpMyAdminが使えないサーバーや、複数のサイトを順に確認したいときに向いています。ただし、修復コマンドが効くのはテーブルの保存形式（ストレージエンジン）がMyISAMなどの場合に限られ、現在の標準であるInnoDBには効きません。この記事では、エンジンの確認から順に、状況に合った修復方法を説明します。内容は2026年10月時点のWP-CLI 2系とMySQL 8.0／MariaDB 10.6以降を前提にしています。
SQLの例はテーブル接頭辞が wp_ の場合です。実際の接頭辞は wp db prefix で確認し、読み替えてください。
作業の前にバックアップを取る
修復の操作はテーブルを書き換えます。失敗したときに戻せるよう、先にデータベースを書き出しておきます。
# WordPress のディレクトリで実行する
cd /var/www/html
wp db export ~/backup-before-repair.sqlテーブルが壊れていて書き出しが途中で失敗する場合は、サーバー会社の自動バックアップなど、別の手段で取ったバックアップがあるかを先に確認しておきます。
WP-CLIは、root ユーザーで実行すると警告を出して止まります。--allow-root を付けて実行することもできますが、作成されるファイルの所有者がrootになるなどの問題が起きるため、Webサーバーの実行ユーザーで実行するほうが安全です。
# Webサーバーの実行ユーザーが www-data の場合
sudo -u www-data wp db checkテーブルのエンジンを確認する
修復方法はエンジンによって変わります。まず、各テーブルのエンジンを確認します。
wp db query "SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY ENGINE, TABLE_NAME;"| エンジン | 修復の方法 |
|---|---|
| MyISAM、Aria（MariaDB）、ARCHIVE、CSV | REPAIR TABLE が使える。wp db repair もこれを使う |
| InnoDB | REPAIR TABLE は使えない。テーブルの再構築か、バックアップからの復元で対処する |
現在のWordPressが作るテーブルは、通常InnoDBです。古いサイトから引き継いだテーブルや、プラグインが作ったテーブルだけがMyISAMのまま残っていることがあります。
wp db check で状態を確認する
wp db check は、wp-config.php のデータベース設定を使って、MySQL付属の mysqlcheck を --check 付きで実行するコマンドです。中では各テーブルに CHECK TABLE が実行されます。
wp db checkテーブルごとに結果が表示され、最後に Success: Database checked. と出ます。OK 以外の行（error、warning、Table is marked as crashed など）が出たテーブルが対象です。
特定のテーブルだけを確認したいときは、SQLを直接実行します。
wp db query "CHECK TABLE wp_options, wp_posts;"wp db check と wp db repair はサーバーに mysqlcheck コマンドが入っていないと動きません。その場合は、wp db query でSQLを直接実行するか、後述の方法を使います。
MyISAMのテーブルを修復する
wp db repair は、mysqlcheck を --repair 付きで実行し、データベース内のテーブルに REPAIR TABLE をかけます。
wp db repair成功すると Success: Database repaired. と表示されます。InnoDBのテーブルについては「The storage engine for the table doesn't support repair」と表示されますが、これはInnoDBが対象外というだけで、エラーではありません。
壊れているテーブルが分かっている場合は、そのテーブルだけを修復できます。
wp db query "REPAIR TABLE wp_options;"
wp db checkTable './データベース名/wp_options' is marked as crashed and should be repaired というエラーは、MyISAMのテーブルが正しく閉じられなかったときに出るもので、多くはこの方法で直ります。直った後は、再発を防ぐために、後述の手順でInnoDBへ変換することを検討します。
InnoDBのテーブルで問題が出たとき
InnoDBは、MySQLの起動時に更新ログを使って自動で復旧する仕組みを持っているため、一時的な停止だけでテーブルが壊れることは多くありません。CHECK TABLE でエラーが出た場合は、次の順に対処します。
テーブルを再構築する
軽い不整合（インデックスの不整合など）は、テーブルを作り直すと解消することがあります。ALTER TABLE ... ENGINE=InnoDB は、エンジンを変えずにテーブルを再構築する書き方です。
# テーブルを再構築してから、もう一度確認する
wp db query "ALTER TABLE wp_options ENGINE=InnoDB;"
wp db query "CHECK TABLE wp_options;"再構築中はテーブルの大きさに応じて時間がかかり、サーバーの負荷も上がります。アクセスの少ない時間帯に実行してください。
それでも直らない、MySQLが起動しない場合
再構築しても CHECK TABLE でエラーが出る場合や、MySQL自体が起動しない場合は、WordPress側の操作では直せません。
- レンタルサーバーでは、サーバー会社のバックアップから復元するか、サポートに問い合わせます
- 自分で管理しているサーバーでは、MySQLの
innodb_force_recovery設定で読み取り専用に近い状態で起動し、データを書き出して作り直す方法があります。データを失う危険がある操作なので、MySQL公式マニュアルの「Forcing InnoDB Recovery」の説明を確認したうえで、小さい値から試してください
MyISAMのテーブルをInnoDBに変換する
MyISAMは、サーバーの異常終了でテーブルが壊れやすい形式です。修復が済んだら、InnoDBへの変換を検討します。
# MyISAM のテーブルを一覧する
wp db query "SELECT TABLE_NAME FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND ENGINE = 'MyISAM';"
# 1テーブルずつ変換する
wp db query "ALTER TABLE wp_options ENGINE=InnoDB;"プラグインが独自に作ったテーブルの中には、MyISAM固有の機能（古いMySQLでの全文検索など）に頼っているものがあります。プラグインのテーブルは、そのプラグインの説明を確認してから変換してください。
mysqlcheck を直接使う
wp db check が使う mysqlcheck は、直接実行することもできます。データベースの接続情報は wp config get で確認できます。
# 接続情報を確認する
wp config get DB_NAME
wp config get DB_USER
wp config get DB_HOST
# 全テーブルを確認し、壊れたテーブルが見つかれば修復する
# -p だけを付けると、パスワードの入力を求められる
mysqlcheck -h localhost -u DBユーザー名 -p --auto-repair データベース名--auto-repair は、確認で壊れていたテーブルを、全テーブルの確認が終わった後に修復するオプションです。修復が効くのはMyISAMなどのテーブルだけで、InnoDBに対しては上と同じく効果がありません。
-pパスワード のようにパスワードをコマンドに続けて書くと、ほかのユーザーからプロセス一覧で見えたり、シェルの履歴に残ったりします。-p だけを付けて入力する方法を使ってください。
WP-CLIが使えないとき（WP_ALLOW_REPAIR）
WordPressには、ブラウザーからデータベースを修復する画面が用意されています。wp-config.php の /* That's all, stop editing! */ より前に次の1行を追加します。
<?php
define( 'WP_ALLOW_REPAIR', true );https://サイトのURL/wp-admin/maint/repair.php を開くと、修復だけを行うボタンと、修復と最適化を行うボタンが表示されます。この画面はログインしていなくても誰でも開けるため、作業が終わったらすぐに wp-config.php から1行を削除してください。
修復できないときはバックアップから戻す
修復しても直らない場合は、壊れる前のバックアップから戻します。インポートすると、同じ名前のテーブルはバックアップの内容で置き換えられます。
wp db import ~/backup-from-last-week.sql
wp db check戻した後は、バックアップを取った時点以降の投稿やコメントが失われていないかを確認します。
定期的な確認について
修復を自動で実行するスクリプトを cron に登録する方法もありますが、壊れたことに気付かないまま修復と再発を繰り返すことになりかねません。定期的に wp db check の結果を記録し、OK 以外の行が出たら人が確認する運用にするほうが、原因（ディスクの不調、メモリー不足によるMySQLの強制終了など）を見つけやすくなります。
まとめ
- 修復の前に
wp db exportでバックアップを取る。WP-CLIはWebサーバーの実行ユーザーで実行する - まずエンジンを確認する。
wp db repair（REPAIR TABLE）が効くのはMyISAMなどで、InnoDBには効かない - 状態の確認は
wp db check。中ではmysqlcheck --checkが動いている - InnoDBの不整合は
ALTER TABLE ... ENGINE=InnoDBで再構築し、直らなければバックアップから戻す - WP-CLIがなければ
WP_ALLOW_REPAIRの修復画面を使い、作業後は設定を削除する - 修復した MyISAM のテーブルは、InnoDB への変換を検討する
関連記事: