コンテンツへスキップ
WordPress保守

wp db check / wp db optimize — 見落とされがちなデータベース健全性コマンド

WordPressのデータベースは、放っておいても勝手に手入れされることはない。スパムコメントの蓄積、期限切れのトランジェント、投稿のリビジョン、削除したはずのプラグインが残したテーブル。こうしたものが積み重なるほどテーブルは肥大化し、まれにテーブル自体が破損することもある。管理画面からは中身が見えにくいこの領域を、WP-CLIはwp db checkとwp db optimizeという2つの短いコマンドで扱える。

補足: WP-CLIのwp db系コマンドは、WordPressが使うMySQL（またはMariaDB）データベースに対して、管理画面を経由せず直接操作を行うサブコマンド群。接続情報はwp-config.phpから自動で読み取られる。

wp db check — テーブルの健全性を確認する

wp db check

このコマンドは、内部的にはmysqlcheck --check相当の処理を全テーブルに対して実行し、各テーブルが正常な状態かどうかを1行ずつ報告する。

wp_posts                       OK
wp_options                      OK
wp_postmeta                     OK

万一いずれかのテーブルがcorruptと報告された場合、そのテーブルに対するSELECTやINSERTが失敗し始める。サイトが「突然、特定のページだけ真っ白になる」「特定の投稿だけ編集できない」といった局所的な不具合として現れることがあり、原因がデータベースの破損だとは気づきにくい。定期的にwp db checkを実行しておけば、症状が表に出る前に異常を検知できる。

wp db optimize — 断片化したテーブルを整理する

wp db optimize

こちらはmysqlcheck --optimize相当で、OPTIMIZE TABLEをテーブルごとに実行する。行の削除・更新を繰り返したテーブルは、ディスク上で断片化した状態になりやすい。OPTIMIZE TABLEはテーブルを再構築し、削除済み行が占めていた領域を解放する。

補足: ストレージエンジンによって挙動が異なる。WordPressの標準ストレージエンジンであるInnoDBでは、OPTIMIZE TABLEは内部的にテーブルの再構築（ALTER TABLE ... FORCE相当）として実行され、断片化の解消と統計情報の更新が行われる。旧来のMyISAMでは、削除された行の領域は自動的には回収されず、OPTIMIZE TABLEを実行して初めてディスク領域が解放される。古いレンタルサーバーの簡単インストールで作られたWordPressにはMyISAMテーブルが残っていることがあるため、ストレージエンジンが混在していないかwp db query "SHOW TABLE STATUS"で一度確認しておくと状況を把握しやすい。

wp db optimizeはOPTIMIZE TABLE実行中、対象テーブルへの書き込みをロックする。テーブルサイズが大きい場合はこの間サイトの応答が一時的に遅くなることがあるため、アクセスの少ない時間帯に実行するのが安全である。

いつ実行するべきか

このコマンド自体はいつ実行しても害はないが、特に効果が出やすいタイミングがある。

  • 大量削除の直後: スパムコメントの一括削除、不要な投稿の一括削除、使わなくなったプラグインのアンインストール直後など、テーブルの行数が急に減った場合
  • メジャーな更新の前: WordPress本体やプラグインの大規模アップデートの前にwp db checkでテーブルの健全性を確認しておくと、更新後の不具合が「更新のせい」なのか「元々あったデータベースの問題」なのかを切り分けやすくなる
  • 定期メンテナンスの一部として: 月次・週次のようなサイクルで機械的に流す運用にしておけば、断片化やテーブル破損を「気づいたときには手遅れ」ではなく「日常的にチェックされている」状態に変えられる

破損が見つかった場合 — wp db repair

wp db checkがcorruptを報告した場合の対処として、wp db repair（mysqlcheck --repair相当）が用意されている。ただし修復は元のデータを完全に復元できる保証があるわけではなく、破損の程度によってはデータの一部が失われる可能性がある。修復を試みる前に、必ずその時点のバックアップを取得しておくことが前提になる。データベースが壊れた状態のバックアップよりも、壊れる直前のバックアップの方がはるかに価値が高い。

まとめ

したいこと コマンド
全テーブルの健全性を確認 wp db check
断片化したテーブルを整理・領域を解放 wp db optimize
破損したテーブルの修復を試みる wp db repair（実行前に必ずバックアップ）
ストレージエンジンの混在を確認 wp db query "SHOW TABLE STATUS"

wp db checkとwp db optimizeはどちらも数秒から数分で終わる軽い操作でありながら、データベースという最も見えにくい領域の状態を証跡として残してくれる。管理画面のプラグイン一覧やダッシュボードには出てこない情報だからこそ、WP-CLIで機械的に定期チェックする価値がある。

WP-CLIが管理画面を経由せずデータベースに直接アクセスできる特性は、wp search-replaceによるシリアライズ安全な置換や管理画面ロックアウトからのWP-CLI復旧でも軸になっている考え方であり、データベースの健全性確認もその延長線上にある基本動作の1つといえる。