WordPressを長く運用すると、データベース容量、バックアップ時間、管理画面の重さが気になることがあります。リビジョンや一時データを削除する最適化プラグインも見つかりますが、何を保存しているか分からないまま実行すると、記事、設定、注文、会員、問い合わせ、復元用の履歴まで失いかねません。
安全な最適化は、最初に削除ボタンを押す作業ではありません。現在の症状と容量を測り、大きいテーブルの所有元と保持理由を特定し、管理画面や提供元の正規機能で一種類ずつ整理する作業です。
「データのクリーンアップ」と「テーブルの最適化」を混同しないでください。クリーンアップは不要と判断したレコードを削除する作業です。MySQLのOPTIMIZE TABLEは物理的な格納とインデックスを再編成する処理で、不要データを選別して削除する機能ではありません。
先に結論｜データベース最適化の安全な順番
- 重い画面、エラー、DB容量、バックアップ時間を記録する
- データベースとWordPressファイルの両方をバックアップする
- 復元方法と、作業中に増える注文・問い合わせ等の差分を確認する
- DB総容量と容量上位のテーブルを調べる
- 各テーブル・データの所有元と保持理由を特定する
- 削除対象、保持期間、件数、戻し方を決める
- テスト環境または低負荷時間に一種類だけ整理する
- 必要な場合だけ、対象を限定してテーブル最適化を行う
- 公開表示、管理、フォーム、注文、予約処理、ログを確認する
- 容量、バックアップ時間、同条件の応答時間を作業前と比較する
データベースが大きいだけで、表示の遅さの原因とは断定できません。遅いSQL、外部API、画像、PHP処理、キャッシュ、テーマ、プラグイン、サーバー資源が原因の場合もあります。速度全体の切り分けはWordPressが重い原因と改善順から始めてください。
WordPressはデータベースに何を保存しているのか
| 主な領域 | 保存されるものの例 | 削除時の影響 |
|---|---|---|
| 投稿・投稿メタ | 記事、固定ページ、リビジョン、添付情報、カスタムフィールド | 本文・設定・表示部品を失う場合がある |
| オプション | WordPress、テーマ、プラグインの設定、一時データ | サイト全体や機能の設定が壊れる場合がある |
| ユーザー・ユーザーメタ | アカウント、権限、プロフィール、拡張情報 | ログイン、権限、会員情報へ影響する |
| コメント・コメントメタ | コメント、スパム、関連情報 | 承認済みコメントや連携情報を失う場合がある |
| ターム関連 | カテゴリー、タグ、分類と投稿の関係 | 分類・URL・記事一覧が崩れる場合がある |
| プラグイン独自テーブル | 注文、予約、フォーム、ログ、ジョブ、統計、キャッシュ | 業務データや処理待ちデータを失う場合がある |
WordPress公式のOptions APIでは、設定データが通常wp_optionsへ保存されると説明しています。ただし、実際のテーブル接頭辞はwp_とは限りません。名前が似ている、古そうに見えるという理由だけで削除しないでください。
画像、テーマ、プラグイン、wp-config.phpは通常サーバー上のファイルです。WordPress公式のBackupsも、一般的な復元にはデータベースとファイルの両方が必要だと案内しています。DBだけを保存して「フルバックアップ」と扱わないことが重要です。
最初に容量と症状を測る
| 記録するもの | 確認する理由 |
|---|---|
| DB総容量 | 作業前後の変化を比べる基準 |
| 容量上位10テーブル | どの機能・データが増えているか絞る |
| データ容量とインデックス容量 | レコード量と索引量を分ける |
| 直近7日・30日の増加 | 継続増加か、一度の移行・処理かを分ける |
| 重いURL・管理画面 | DB全体ではなく特定処理の問題か確認 |
| バックアップ所要時間 | 容量・件数増加の運用影響を測る |
| PHP・DBエラー時刻 | 遅延と具体的な失敗を照合する |
| 直前の導入・更新 | プラグイン、移行、インポート、ログ設定との関係を見る |
契約サーバーのDB容量画面、phpMyAdminのテーブル一覧、保守担当の読み取り専用調査、WP-CLIのwp db sizeなど、現在の環境で公式に案内された方法を使います。コマンドやSQLに慣れていない場合は、削除権限を持つ画面を触る前にサーバーサポートへ上位テーブルの確認方法を聞きます。
総容量より、どのテーブルが、いつから、何のデータで増えたかが重要です。注文が増えたECサイト、アクセスログを保存するサイト、数万記事のメディアでは、必要なDB容量も異なります。他サイトの「何MBなら大きい」という数字をそのまま基準にしません。
バックアップは「取った」より「戻せる」を確認する
- DBエクスポートの取得日時とファイルサイズ
- WordPressファイル、uploads、テーマ、プラグインの保存範囲
- バックアップが本番サーバーと別の場所にあるか
- 復元に必要な管理画面・認証情報・手順
- テスト環境へ復元して内容を確認できるか
- 作業開始後に増える注文、問い合わせ、会員登録、コメント
- 復元時に失われる時間帯とデータの範囲
データベース操作は、現在のデータを書き換えます。作業中も更新されるサイトでは、開始時点のバックアップへ全体復元すると、その後の注文や問い合わせが消える可能性があります。保守時間、受付停止の要否、差分の退避方法を運営担当と決めます。
基本の保存範囲はWordPressバックアップの取り方で確認し、大きな削除はWordPressテスト環境の作り方に沿って複製環境で試します。バックアップファイルを本番の公開ディレクトリへ置きっぱなしにしないでください。
削除候補を所有元と保持理由で分類する
| 候補 | 最初に確認すること | 安全な入口 |
|---|---|---|
| 投稿リビジョン | 復元に必要な期間、記事更新の頻度、保持数 | WordPressのリビジョン仕様、対応ツールの公式機能 |
| スパム・ごみ箱 | 誤判定、承認待ち、保持期間 | WordPress管理画面 |
| 期限切れ一時データ | 所有元、期限、再生成可否、オブジェクトキャッシュ | 提供元の保守機能・API |
| 自動読み込みオプション | 名前、容量、所有プラグイン・テーマ、現在の利用 | サイトヘルス、提供元、ホスティング |
| 停止済みプラグインのテーブル | 本当に停止済みか、再導入・移行・履歴に必要か | アンインストール手順、提供元サポート |
| ログ・分析・ジョブ履歴 | 保持期間、監査・障害調査・再実行の必要性 | プラグインの保持設定 |
| 注文・会員・フォーム | 業務、会計、法務、サポート上の保持要件 | サイト運営責任者と提供元 |
「未使用」「孤立」「期限切れ」と表示するツールも、サイト固有の独自コードや外部連携まで理解しているとは限りません。所有元が分からないデータは削除候補ではなく調査対象です。バックアップがあっても、必要データを消してよい根拠にはなりません。
リビジョンは復元価値を決めてから整理する
リビジョンは単なるごみではなく、記事の過去版を比較・復元する仕組みです。WordPress公式のRevisionsでは、保存済みの変更履歴を比較して戻せること、リビジョン数を設定できることが説明されています。
- 公開記事を何日・何版まで戻す必要があるか
- 複数編集者が同じ記事を更新するか
- 法務・監修・広告表現の変更履歴が必要か
- バックアップで記事単位の復元ができるか
- 古いリビジョンがDB全体の何割を占めるか
今後の保持数を制限する場合、公式資料にあるWP_POST_REVISIONSをwp-config.phpで設定できます。ただし、値を追加しただけで過去の全リビジョンが直ちに安全に整理されるとは限りません。編集方針を決め、設定ファイルのバックアップとテストを行い、重複定義を避けます。
define( 'WP_POST_REVISIONS', 10 );「10」はすべてのサイトの推奨値ではなく例です。頻繁に更新する記事とほとんど変えない固定ページでは必要な履歴が異なります。過去分を削除する場合は、対象件数を確認でき、提供元が現行WordPressへの対応を明示する方法を使います。
スパム・ごみ箱・一時データは正規機能から整理する
コメントスパムやごみ箱は、まずWordPress管理画面で誤判定がないか確認してから削除します。SQLでコメントテーブルを直接空にすると、承認済み、保留、トラックバック、プラグイン独自状態の区別を誤る可能性があります。
transientは期限付きの一時データとして使われますが、テーマやプラグインの実装、外部オブジェクトキャッシュの有無で保存場所と挙動が異なります。期限切れと表示されても、提供元の保守機能やWordPress APIを優先し、option_nameの文字列だけで一括削除しません。
ログやジョブ履歴は、容量削減だけでなく再発防止が必要です。保持期間、最大件数、詳細ログの有効期限、失敗ジョブの再試行をプラグイン設定で見直します。毎日増える原因を残したまま手動削除を繰り返すと、証拠だけが消え、容量は再び増えます。
自動読み込みオプションは一括削除しない
自動読み込みオプションは、WordPressの各ページ要求でまとめて読み込まれる設定です。WordPress公式のOptimizationでは、多すぎる自動読み込みデータが速度へ影響し得ると説明し、一般的な目安として800KB未満を挙げています。
ただし800KBは、超えた項目を自動削除してよい境界ではありません。サイトヘルスの警告は調査開始の合図です。大きいオプション名、容量、所有元、現在のテーマ・プラグインで使うか、削除後に再生成できるかを確認します。
- サイトヘルスの警告全文を保存する
- 大きい自動読み込みオプションを容量順に確認する
- 名称と現行テーマ・プラグインの設定を照合する
- 提供元の削除・移行・キャッシュ再生成手順を確認する
- 不明なら削除せず、提供元または保守担当へ問い合わせる
- テスト環境で一項目だけ変更し、公開・管理・予約処理を確認する
記事033のWordPressサイトヘルスの見方でも、自動読み込みオプションをDBから直接削除せず、原因プラグイン・テーマの提供元や保守担当へ確認する方針を案内しています。
停止済みプラグインのテーブルを削除する前の確認
- 現在は本当に停止・削除済みか
- 同じ開発元の別プラグインが使っていないか
- マルチサイトや別サイトが共有していないか
- 設定、フォーム送信、注文、会員、分析、監査ログを含まないか
- 再導入、移行、返金、問い合わせ対応で履歴が必要ないか
- 公式アンインストール機能で削除できるか
- テーブル接頭辞と実際の所有元が一致するか
プラグインを管理画面から削除しても、再導入時のため設定やテーブルを残す製品があります。それだけで「残骸」とは断定できません。プラグイン整理の判断はWordPressプラグインを減らす方法で依存関係と代替機能を確認してください。
所有元の公式アンインストール手順があり、保持不要と運営者が判断し、テスト復元もできる場合に限り削除対象とします。削除するテーブル名、件数、容量、日時、担当者、バックアップを作業記録へ残します。
OPTIMIZE TABLEを実行する前に知ること
MySQL公式のOPTIMIZE TABLEは、テーブルデータとインデックスの物理格納を再編成し、未使用領域の回収やI/O効率の改善を図る処理です。実際の動作と効果はストレージエンジンやテーブル構成に依存します。
| 確認項目 | 理由 |
|---|---|
| 大量の削除・更新があったか | 再編成を検討する根拠 |
| ストレージエンジンとサーバー仕様 | 再構築、領域回収、ロックの挙動が異なる |
| 一時的な空き容量 | テーブル再構築で追加領域が必要な場合がある |
| テーブルサイズと処理時間 | 大きいテーブルでは長時間化する可能性 |
| 書き込みが少ない時間 | 注文・投稿・ジョブへの影響を減らす |
| バックアップと戻し方 | 失敗・中断時に復旧するため |
| サーバー公式の実行方法 | 共有環境では権限・制限・推奨手順が異なる |
WP-CLIのwp db optimizeは、WordPressの接続情報を使ってmysqlcheck --optimizeを実行します。コマンドが存在することと、本番で今実行すべきことは別です。共有サーバーでは管理画面の最適化機能やサポート案内を優先します。
最適化、修復、クリーンアップを複数ツールで同時に動かさないでください。対象テーブルの再構築中に別ツールが削除・更新すると、負荷、ロック、失敗時の原因特定が難しくなります。一種類の作業が完了し、検証できてから次へ進みます。
修復機能は定期最適化の代わりではない
WordPressにはWP_ALLOW_REPAIRで有効にするデータベース修復画面がありますが、通常の容量整理で常用する機能ではありません。公式のwp-config.php解説では、有効中はログインなしで修復ページへアクセスできるため、必要なときだけ有効にし、解決後に無効化するよう注意しています。
具体的な破損エラーがないのに、接続確立エラー、遅延、容量増加を理由として修復を実行しません。接続障害は認証情報、DBサービス停止、容量、負荷でも起きます。症状が接続エラーならWordPressのデータベース接続確立エラー対処法で先に原因を分けます。
作業は一種類ずつ小さく行う
- 対象データの種類、所有元、件数、容量を記録する
- 保持期間と削除してよい理由を運営担当と確認する
- バックアップと復元テストを確認する
- テスト環境で同じ機能と削除方法を試す
- 本番の低負荷時間と受付停止の要否を決める
- 管理画面または提供元の機能で一種類だけ削除する
- 公開ページ、管理画面、保存、検索、フォーム等をテストする
- DB容量、エラー、処理時間を記録する
- 必要性が確認できた場合だけ対象テーブルを最適化する
- 翌日と次回定期処理後に再発・欠損がないか確認する
たとえば「スパムを確認して削除→検証」「古いリビジョンを限定して削除→検証」「一つのプラグインの期限切れログを削除→検証」と分けます。リビジョン、transient、全プラグインテーブルを一括選択すると、どの操作が不具合を起こしたか追えません。
ディスク空き不足が出ている場合は、最適化の再構築に必要な一時領域を確保できない可能性があります。バックアップを本番内へ追加してさらに容量を圧迫せず、WordPressの507 Insufficient Storage確認順でファイル、inode、DB、メール、外部保存先を分けてください。
作業後は容量・機能・速度を同じ条件で比較する
| 確認領域 | 確認内容 |
|---|---|
| データ | 最新記事、固定ページ、ユーザー、コメント、注文、問い合わせが残る |
| 公開表示 | トップ、主要記事、検索、カテゴリー、画像、ログインが正常 |
| 管理 | 投稿保存、メディア、設定、更新、ユーザー管理が正常 |
| 定期処理 | バックアップ、予約投稿、メール、同期、ジョブが完了する |
| DB | 総容量、対象テーブル容量、エラー、増加速度 |
| 速度 | 同じURL・時間帯・キャッシュ条件の応答を比較 |
| 復元 | 作業前バックアップを保持し、保存場所と期限を記録 |
| 記録 | 削除対象、件数、方法、担当、日時、結果、戻し方を保存 |
一回のPageSpeedスコアだけで高速化を断定しません。キャッシュ有無、回線、外部スクリプト、サーバー負荷で値が変わるため、同じページを同じ条件で複数回測ります。DB容量が減っても表示速度が変わらなければ、原因が別にある可能性があります。
再び肥大化させない運用
- DB総容量と上位テーブルを月次または四半期で記録する
- ログ、分析、ジョブ履歴の保持期間と最大件数を決める
- リビジョン保持数を編集・監修方針に合わせる
- スパム・ごみ箱を誤判定確認後に定期整理する
- プラグイン削除時にデータ保持・削除方針を記録する
- 自動読み込み警告を名前・容量・所有元まで調べる
- バックアップ時間と復元テスト結果を記録する
- 大きなインポート、移行、ログ詳細化の前後で容量を比較する
- 最適化を予定表どおり無条件に実行せず、必要性を確認する
点検を属人化しないため、WordPress保守・メンテナンスのチェックリストへDB容量、上位テーブル、バックアップ時間、保持設定を追加します。異常増加を小さい段階で見つければ、大規模な一括削除を避けられます。
自分で進めず相談する基準
- 上位テーブルの所有元を特定できない
- 注文、会員、予約、決済、フォーム、会計データを含む
- マルチサイトや複数アプリが同じDBを使う
- バックアップの復元確認ができない
- 十分な空き容量や保守時間を確保できない
- テーブル破損、接続エラー、書き込み失敗が同時に出る
- 数百万件以上の削除や巨大テーブル再構築が必要
- SQL、WP-CLI、phpMyAdminの操作に不慣れ
- 作業中も注文・問い合わせを止められない
サーバー会社や保守担当へは、DB総容量、上位テーブル、増加時期、対象機能、エラー時刻、バックアップ状況、直前の変更を伝えます。「DBを軽くしてください」だけでなく、削除してよいデータと保持期間をサイト運営者側で示すと判断しやすくなります。
やってはいけない対応
- 大きいテーブルを不要と決めつけて削除する
- 接頭辞やプラグイン名だけで所有元を断定する
- 自動読み込みオプションをSQLで一括削除する
- 注文、会員、フォーム、ログの保持要件を確認しない
- バックアップを本番サーバー内だけに置く
- 復元テストなしで全リビジョン・全transientを消す
- クリーンアップ、修復、最適化を同時実行する
- 空き容量不足のまま巨大テーブルを再構築する
- WP_ALLOW_REPAIRを作業後も有効にしておく
- 容量が減っただけで速度改善・完了と判断する
よくある質問
データベース最適化で必ずWordPressは速くなりますか？
必ずではありません。不要データや大きい自動読み込みオプションが原因なら改善する可能性がありますが、画像、PHP、外部API、キャッシュ、テーマ、サーバー負荷が原因ならDB容量を減らしても変わりません。作業前後を同条件で測ります。
最適化プラグインを入れれば安全ですか？
プラグインも削除対象とサイト固有の必要性を完全には判断できません。現行WordPressへの対応、更新履歴、削除対象の事前表示、バックアップ、対象除外、復元方法を確認し、全項目の一括実行を避けます。
リビジョンは全部削除してよいですか？
おすすめしません。リビジョンは誤編集や更新前の内容へ戻すための履歴です。必要な保持期間と版数を決め、削除前に記事単位の復元、監修履歴、バックアップで代替できるか確認します。
データベース修復と最適化は同じですか？
同じではありません。修復は具体的なテーブル問題へ対処する処理、最適化は物理格納やインデックスを再編成する処理です。容量が大きい、サイトが遅いという理由だけで修復を実行せず、エラー内容とサーバー仕様を確認します。
まとめ｜削除する前に測り、所有元と保持理由を確認する
WordPressデータベースの最適化は、不要そうな項目をまとめて消す作業ではありません。症状、総容量、上位テーブル、増加時期を測り、WordPressコア、現行プラグイン、停止済みプラグイン、業務データのどこが所有するかを特定します。
DBとファイルのバックアップ、復元方法、作業中に増えるデータを確認し、一種類ずつ正規機能で整理してください。大量削除後など必要性がある場合だけ、空き容量、処理時間、ロック、サーバー仕様を確認してテーブルを最適化します。最後に容量、主要機能、エラー、バックアップ時間、同条件の速度を比較し、保持期間と定期計測まで決めて完了です。