WordPressデータベース最適化｜リビジョン・transient・autoloadを安全に整理する方法

WordPressを長く運営すると、記事数だけでなくリビジョン、transient、プラグイン設定、削除済みプラグインの残骸などがデータベースへ積み上がります。ただしDBサイズが大きいこと自体を悪と決めると危険です。ECや会員サイトは業務データが多くて当然だからです。

まず「何が大きいか」を分ける

wp_optionsが大きい時の見方

wp_optionsにはサイトURLのような基本設定だけでなく、プラグイン設定、キャッシュ、cron配列など多様な値があります。テーブル全体が大きいからといって一括削除できません。まずautoload対象と非autoload対象を分け、そのうえで大きいoptionを所有者別に見ます。

また、autoload総量が警告閾値を超えていても、すべてが不要とは限りません。毎ページ必要な値はautoloadする方が効率的です。問題は「毎ページ不要なのに大きく、しかも多数ある」状態です。

なお、データベース接頭辞は必ずwp_とは限りません。セキュリティや既存環境の都合で変更されているサイトでは、実際のoptionsテーブル名を確認してから操作します。記事中のwp_optionsは標準接頭辞の例として読んでください。

autoloadはSite Healthから確認する

WordPress 6.6以降はSite Healthでautoloaded optionsの総量を監視でき、既定では約800KBを超えると重要な問題として表示される仕組みがあります。これは「800KBを超えたら即削除」という意味ではなく、調査開始のシグナルです。

WordPress 6.6では大きなoptionの自動autoloadを抑える仕組みも強化されています。古いサイトでは過去に作られたyes/no値が残っているため、新規サイトと同じ挙動とは限りません。

WordPress 6.6以降で知っておきたい2つのautoload基準

この2つは別の基準です。150KBは新規・更新optionのautoload判断、800KBはサイト全体のautoload総量を監視する目安です。数値を一括削除ルールとして使わず、所有プラグインと用途を確認します。

DB最適化の前後で残す証跡

最適化前に、DB総容量だけでなくテーブル別サイズ、autoload総量、リビジョン件数、期限切れtransientの件数を残します。実行後に同じ数字を取り、どの変更で何が減ったかを記録します。これにより「プラグインを実行したから速くなったはず」ではなく、具体的な変化を追えます。

安全な最適化の順番

1. ファイル＋DBの復元可能なバックアップを取得
2. DBサイズと大きいテーブルを確認
3. Site Healthのautoload警告を確認
4. リビジョンの保持方針を決める
5. 期限切れtransientを確認
6. 使っていないプラグインの独自テーブルを確認
7. 1種類ずつ変更して表示・管理画面・CronをQA

大きなautoload optionを見つけたら

option名だけで削除せず、まず作成元プラグインを特定します。現役プラグインなら、その設定画面で不要機能をOFFにする、キャッシュを再生成する、公式のcleanup手順を使う方が安全です。削除済みプラグインの残骸でも、再導入予定やライセンス情報がないか確認します。

WordPress 6.6以降は大きなoptionを自動autoloadしない方向へ改善されていますが、過去に作られたデータは自動で全部最適化されるわけではありません。古いサイトほどSite Healthを定期的に見る意味があります。

リビジョンは何件残す？

リビジョンは単なる「不要データ」ではなく、公開事故から戻すための編集履歴です。記事を頻繁に編集するサイトや、AI/APIで一括更新する運用では直前版へ戻せる価値が高いため、保持数を0にするより「必要十分な世代」を決めます。

一方、自動保存や大量編集で数千件積み上がる場合は保持数を設計する価値があります。更新頻度の高いサイトと、ほぼ固定のサイトで同じ上限にする必要はありません。削除前に、実際に戻したい履歴が残っているかを確認します。

transientは「期限切れ＝必ずDBにある」ではない

WordPressのTransients APIは、外部object cacheが有効ならDB以外へ保存されることがあります。またexpirationは「最大保持時間」であり、それより早く消えることもあります。プラグインの仕組みを無視してDBだけ直接掃除するより、WordPress APIや信頼できる運用ツールを使う方が安全です。

transientは「期限あり」と「期限なし」でautoloadが変わる

persistent object cacheがない通常環境ではtransientはDBへ保存されます。期限付きtransientは原則autoloadされませんが、expirationを指定しないtransientはautoload対象になります。大量の「期限なしtransient」があると、名前はtransientでも毎リクエストのautoload負荷になり得ます。

RedisやMemcachedなどpersistent object cacheが有効な場合、transientはDBではなくobject cache側に保存されることがあります。したがってDB掃除記事の手順を全サイトへ一律適用せず、まずキャッシュ構成を確認します。

postmeta・termmetaが肥大化している場合

カスタムフィールド、SEOプラグイン、EC、ページビルダーはmetaを多く使います。投稿数が増えるほど自然に大きくなるので、容量だけで異常判定しません。削除済み投稿に紐づいたorphan dataや、使わなくなったプラグインのキーが大量に残っていないかを調べます。

最適化プラグインを使う場合の注意

ワンクリックcleanupは便利ですが、何を消すかを一覧で見られるものを選びます。実行前にDBバックアップを取り、最初はrevisionsだけ、次にexpired transientsというように対象を分けます。複数種類を一度に削除すると、不具合発生時に原因を戻しにくくなります。

DB最適化とバックアップの順番

最適化のためにバックアップを取ると、そのバックアップ自体がサーバー容量を圧迫する場合があります。保存先を外部へ逃がす、圧縮後にローカルへ取得するなど、復元可能性を保ちながら本番ディスクを圧迫しない方法を選びます。最適化後もすぐバックアップを消さず、数日運用して問題がないことを確認してから世代整理します。

DB最適化を定期化するなら

毎日自動削除する必要はありません。月1回や四半期ごとにSite Healthを確認し、閾値を超えた時だけ対応する方が安全です。自動cleanupを使う場合も、対象項目と保持世代を固定し、EC注文や会員データが対象外であることを確認します。

SQLを直接書く前にSite Health・WP-CLI・プラグイン公式機能を使う

DBを直接DELETEする方法は速い一方、対象を誤ると復旧が必要になります。まずSite Health、プラグイン自身のcleanup機能、WP-CLIなどWordPressの状態を理解した経路を使い、直接SQLは復元可能なバックアップと検証環境がある時の上級手段として扱います。

DB最適化でやらない方がいいこと

• 本番でバックアップなしにSQLを直接実行
• wp_optionsをサイズだけで一括削除
• EC・会員・予約データをブログと同じ基準で掃除
• キャッシュプラグインを複数入れて「最適化」を重ねる
• DBが小さくなっただけで高速化成功と判断する

改善効果の測り方

最適化後の確認期間

削除直後だけでなく、数日間の投稿保存、検索、Cron、バックアップを確認し、問題がなければ最適化前バックアップを通常の保存ポリシーへ戻します。

Redisを入れる前にDBを整える理由

Redisは繰り返しクエリを減らせますが、不要なautoloadや異常なクエリを直す代替ではありません。先にDB構造を整え、まだ管理画面やログイン利用者が遅いなら145のpersistent object cacheを検討します。全体の速度診断は150、復元用バックアップは既存バックアップ記事へ分けています。

公式情報・参考資料

• WordPress 6.6 Performance Improvements
• Transients API
• Options API: autoload changes

まとめ

WordPress DBの最適化は「掃除」より「原因特定」です。autoload、revisions、transients、plugin tablesを分け、1変更ずつ効果と副作用を確認します。バックアップと切り戻しがある状態で進めれば、速さだけでなく保守性も上げられます。