エラーの内容
WordPressサイトまたは管理画面を開こうとすると、白紙のページまたは以下のようなデータベースエラーが表示されます：
WordPress database error: Table 'wp_options' is marked as crashed and should be repaired
for query SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
何も表示されません。トップページも、wp-adminも — 何も。完全なエラーページが表示される場合もあれば、白い画面だけになる場合もあります。いずれにせよ、wp_optionsが読み取れない状態のため、WordPressはコアの設定を読み込めていません。
発生原因
wp_optionsはWordPressの根幹をなすテーブルです。サイトURL、有効化済みプラグイン、テーマ設定、および自動読み込みされるすべての値が格納されています。一般的なサイトでは、このテーブルには500〜2,000行以上のデータがあり、WordPressはページリクエストのたびにすべての行を参照します。
このようなクラッシュは、主に以下の原因で発生します：
- 書き込み中にサーバーの電源が落ちたり、強制再起動が行われた
- 書き込み操作中に
mysqldプロセスが強制終了された - 書き込み中にディスクの空き容量がなくなった
- テーブルがMyISAMで動作しており、クラッシュ回復機能が一切ない
MyISAMにはクラッシュ回復機能がありません。書き込みが中断されると、インデックスファイルとデータファイルの整合性が崩れます。MySQLはこの不一致を検出し、テーブルをクラッシュ状態としてマークします。
手順1：クラッシュしているテーブルを確認する
wp_optionsだけとは限りません。SSHでログインし、コアテーブルをすべて一度に確認しましょう：
mysql -u your_db_user -p your_database_name
次に以下を実行します：
CHECK TABLE wp_options, wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_terms, wp_term_relationships, wp_term_taxonomy, wp_commentmeta, wp_comments;
Msg_textカラムでcrashedと表示されているものを確認してください。影響を受けているテーブルをすべてメモしておくと、一括で修復できます。
手順2：MySQL CLIでテーブルを修復する（最速の方法）
MySQLシェル内で以下を実行します：
REPAIR TABLE wp_options;
複数のテーブルがクラッシュしている場合は、まとめて修復できます：
REPAIR TABLE wp_options, wp_posts, wp_postmeta;
期待される出力結果：
+--------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------+--------+----------+----------+
| yourdb.wp_options | repair | status | OK |
+--------------------+--------+----------+----------+
OKと表示されれば修復成功です。\qでMySQLを終了し、サイトを再読み込みしてください。
手順3：mysqlcheckで修復する（MySQLログイン不要）
MySQLの対話モードに入らずシェルで作業したい場合は、mysqlcheckを直接使用します：
mysqlcheck -u your_db_user -p --repair your_database_name wp_options
WordPressデータベース全体を一括でスキャン・修復するには：
mysqlcheck -u your_db_user -p --auto-repair --check your_database_name
すべてのテーブルをチェックし、壊れているものだけを修復して、正常なものはスキップします。手動での確認は不要です。
手順4：phpMyAdminで修復する（SSHアクセスなしの場合）
SSHが使えない場合も、phpMyAdminで問題なく対応できます：
- ホスティングのコントロールパネル（cPanel → phpMyAdmin）からphpMyAdminを開く
- 左サイドバーからWordPressのデータベースを選択する
- テーブル一覧から
wp_optionsを探す — 赤いアイコンや「crashed」のステータスが表示されている場合あり - 隣のチェックボックスにチェックを入れる
- ページ下部のドロップダウンを開き、テーブルを修復するを選択する
- 実行をクリックする
修復が成功すると確認メッセージが表示されます。
手順5：WP-CLIで修復する（自動化に最適）
WP-CLIを使っている場合は、最もシンプルな方法が利用できます：
wp db repair --path=/var/www/html/your-wordpress-folder
このコマンドはWordPressデータベース全体に対してmysqlcheck --repairを実行します。cronジョブや複数サイトを同一サーバーで管理している場合に最適です。
修復後にデータベースの状態を確認するには：
wp db check --path=/var/www/html/your-wordpress-folder
修復の確認
修復したテーブルに対して簡単なヘルスチェックを実行します：
mysql -u your_db_user -p your_database_name -e "CHECK TABLE wp_options;"
crashedではなくOKと表示されることを確認してください：
+--------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------+-------+----------+----------+
| yourdb.wp_options | check | status | OK |
+--------------------+-------+----------+----------+
WordPressサイトとwp-adminを開いてください。正常に戻っていれば完了です。
再発防止策
根本的な解決策は、MyISAMからInnoDBへの変換です。InnoDBはトランザクションログを使用しているため、予期せぬシャットダウン後も自動的にロールバック・復旧が行われます。今回のようなクラッシュは発生しなくなります。
まず、現在テーブルが使用しているエンジンを確認します：
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name';
wp_optionsのみを変換する場合：
ALTER TABLE wp_options ENGINE = InnoDB;
すべてのMyISAMテーブルを一括変換するシェルのワンライナー：
mysql -u your_db_user -p your_database_name -e \
"SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;') \
FROM information_schema.TABLES \
WHERE TABLE_SCHEMA = 'your_database_name' AND ENGINE = 'MyISAM';" \
| grep ALTER | mysql -u your_db_user -p your_database_name
MySQL 8.x と MariaDB 10.x では、新規インストール時のデフォルトエンジンはInnoDBです。2015年以前に作成されたデータベース、または古い共有ホスティングから移行したデータベースは、今もMyISAMで動作していることが多くあります。
変換後は、wp db checkをもう一度実行して、すべてが正常であることを確認してください。