Hara Daizo 
WordPressの投稿本文、設定、ユーザー、コメントなど、多くの情報はMySQLまたはMariaDBのデータベースへ保存されます。画像そのものは通常uploadsディレクトリのファイルですが、その画像のタイトルやURLに関する情報はデータベース側にも記録されます。
データベースを直接操作すると、管理画面では戻せない変更を一瞬で行えてしまいます。構造を理解することと、日常的にSQLで編集することは別です。初心者はまず「何がどこに保存されるか」を知り、不要データの整理もWordPressや信頼できる保守機能から行い、phpMyAdminで変更する場合は必ずバックアップを先に取ってください。
WordPressのデータベースとは？役割と構造
WordPressはPHPからデータベースへ問い合わせ、必要な投稿・設定・ユーザー情報を取得してページを組み立てます。WordPress開発では$wpdbというデータベースアクセス用クラスが用意され、プラグインやテーマもこれを通じてデータを読み書きできます。
標準的なシングルサイトでは、次のテーブル群が中心になります。実際の接頭辞はwp_とは限らず、プラグインやマルチサイトによって追加テーブルも作られます。
| テーブル例 | 主な内容 |
|---|---|
*_posts | 投稿、固定ページ、添付ファイル、カスタム投稿タイプなど |
*_postmeta | 投稿にひも付く追加情報 |
*_options | サイトURL、テーマ・プラグイン設定、各種オプション |
*_users / *_usermeta | ユーザーとユーザー追加情報 |
*_comments / *_commentmeta | コメントとその追加情報 |
*_terms / *_term_taxonomy / *_term_relationships / *_termmeta | カテゴリー、タグ、タクソノミーと投稿との関係 |
*_links | 旧来のリンク管理用データ |
投稿を削除しても、プラグイン独自テーブルやメタデータが必ず同時に整理されるとは限りません。一方で、名前だけを見て「不要そう」と判断してテーブルを削除するとサイト機能を壊す可能性があります。削除対象は、作成元のプラグインやデータの用途を確認してから決めます。
phpMyAdmin等でデータベースを確認する
多くのレンタルサーバーでは、データベース管理画面としてphpMyAdminが提供されています。画面名やログイン方法はサーバーごとに違いますが、テーブル一覧、構造、データ参照、検索、エクスポートなどを確認できます。
初めて開く場合は、まず読み取りだけに使うのがおすすめです。wp-config.phpのDB名と接頭辞を確認し、phpMyAdminで同じデータベースを開いて、どのテーブルがWordPress本体・プラグインに対応しているかを把握します。
- 対象データベース名が正しいか
- テーブル接頭辞が自分のサイトと一致しているか
- 作業前のバックアップ日時が十分新しいか
- 本番ではなくステージングで試せるか
- 削除・UPDATE・DROPなど元に戻しにくい操作を実行しようとしていないか
SQLを直接実行する必要がある場合も、ネット上のコードをそのまま貼り付けず、対象テーブル・WHERE条件・影響行数を確認します。WordPress側のコードからSQLを扱う場合も、外部入力を直接連結せず$wpdb->prepare()など適切な方法で値を扱う必要があります。
データベースを最適化する前に不要データを整理する
「データベース最適化」には、不要なレコードを減らす作業と、DBエンジン側でテーブルを再編成する作業が混在しがちです。先に不要データの種類を特定し、その後でテーブルメンテナンスが必要かを判断します。
リビジョン・自動下書き
投稿の編集履歴であるリビジョンは、長期間運用すると増えることがあります。ただし、履歴は誤編集から戻すためにも使うため、件数だけを理由に全削除しないでください。削除方法と保持数の考え方はWordPressリビジョンの整理へ分離します。
期限切れTransientやプラグイン残存データ
一時キャッシュとして使われるTransientや、削除済みプラグインが残したオプション・テーブルが候補になる場合があります。ただし、optionsテーブルの項目はWordPress本体やテーマも使うため、名前だけで削除しないでください。プラグインのアンインストール仕様と公式ドキュメントを確認します。
コメント・スパム・ゴミ箱
スパムコメントやゴミ箱の投稿など、管理画面から用途を確認できるデータは、直接SQLを使う前にWordPress側の機能で整理する方が安全です。削除後に必要な復元期間も考慮します。
OPTIMIZE TABLEは削除とは別の処理
MySQLのOPTIMIZE TABLEは、テーブルの物理的な再編成や統計情報の更新などに使われるメンテナンス処理です。不要レコードを自動判定して消す機能ではありません。ストレージエンジンやテーブル状態によって動作・効果が変わり、大きなテーブルでは時間がかかることもあります。
そのため「最適化ボタンを押せば必ず高速化する」と考えず、データサイズ、遅いクエリ、サーバー負荷など、実際の問題を確認してから実行します。ホスティングや管理ツールが最適化機能を提供している場合は、その対象と復元方法を先に確認してください。
データベースのバックアップを必ず先に取る
データベースを直接変更する前には、現在の状態へ戻せるバックアップが必要です。ファイルだけを保存しても、投稿・設定・ユーザーなどDB内のデータは戻せません。
バックアップ手段、保存先、復元テストについてはWordPressバックアップの方法で詳しく扱っています。phpMyAdminのエクスポートを使う場合も、文字コード・テーブル数・ファイルサイズを確認し、重要なサイトではサーバー側バックアップ等と二重化すると安全です。
安全なデータベース最適化の手順
- バックアップを取得し、復元できる手段を確認する
- DBサイズや遅延など、解決したい問題を言語化する
- 管理画面から削除できるゴミ箱・スパム等を先に整理する
- プラグイン由来のデータは作成元と削除仕様を確認する
- 大きなテーブルと増加しているデータ種別を確認する
- 必要な場合だけ、ステージング環境でテーブル最適化やSQLを試す
- 本番反映後に表示、管理画面、検索、フォーム、ログインなど主要機能を確認する
最適化は定期イベントとして機械的に実行するより、データの増え方とサイトの症状に合わせて行う方が安全です。EC・予約・会員サイトでは、作業中にもデータが増えるため、メンテナンス時間とバックアップ時点を特に意識します。
データベース関連のエラーと切り分け
「データベース接続確立エラー」が表示されたときに、最初からテーブルを編集するのは避けます。サーバー障害、DBホスト・ユーザー・パスワード、権限、接続上限、破損など原因が複数あるため、安全な順に切り分けます。
具体的な復旧手順はデータベース接続確立エラーの対処へ分離しています。この記事ではDB構造を理解することに留め、復旧目的でwp_optionsやユーザーテーブルを直接書き換える手順は扱いません。
データベースが大きいだけで異常とは限らない
投稿数、注文数、アクセスログ系プラグイン、検索インデックスなど、サイト機能によってDBサイズは大きく変わります。「何MB以上なら異常」という共通基準はありません。増加しているテーブルと、そのデータが必要な期間を見て判断します。
遅い原因がデータベースとは限らない
ページ表示が遅い場合、画像、外部API、PHP処理、キャッシュ、JavaScriptなど別の原因もあります。DBサイズだけを見て大量削除を行う前に、実際にどの処理が時間を使っているかを測定してください。
よくある質問
一律の頻度で必須ではありません。不要データの増加や実際の性能問題を確認し、バックアップを取ったうえで必要な処理だけを行います。
用途を確認せず削除するのは危険です。WordPress本体、テーマ、プラグインの重要設定が保存されているため、作成元と復元方法を確認してから操作してください。
画像ファイルそのものは通常データベースではなくuploadsディレクトリにあります。完全復旧にはDBとファイルの両方をバックアップする必要があります。
まとめ
WordPressのデータベースは投稿・設定・ユーザーなどサイトの中核データを保存しています。主要テーブルの役割を理解するとトラブル調査に役立ちますが、直接編集は高リスクです。まずバックアップを取り、管理画面で安全に整理できるデータから処理し、不要データ削除とOPTIMIZE TABLEを分けて考えてください。DB接続エラーやリビジョン削除は専用手順へ分離し、目的が明確な操作だけを行うことが重要です。