WordPressのDBが肥大化する原因と対策　― リビジョン機能の設定方法とDB断片化を解消する最適化手順 ―

WordPressのDBが肥大化する最大の原因は「リビジョン」

WordPressのDB容量増加にはさまざまな要因がありますが、実務で最も多く見かけるのがリビジョンによる肥大化です。

WordPressでは、投稿や固定ページを更新するたびに、過去の状態がリビジョンとして wp_posts テーブルに保存されます。たとえば、1記事を10回更新すれば、最新の投稿とは別に10件分のリビジョンが自動生成されます。

これが数百・数千記事規模になると、以下のような状態に陥ります。

• 実体の投稿数は少ないのに wp_posts が異常に大きい
• wp_postmeta もリビジョン分だけ増え続ける
• DBバックアップや最適化に時間がかかる

リビジョン機能がONのまま無制限で運用されているサイトほど、DB肥大化のリスクが高くなります。

---

リビジョンがDB容量に与える影響

リビジョンは「履歴」ですが、DB上では通常の投稿データとほぼ同じ扱いになります。そのため、次のような特徴があります。

• post_type = revision として wp_posts に保存される
• 本文だけでなく、メタデータ（wp_postmeta）も増える
• 削除しない限り永続的に残る

一時的な履歴のつもりでも、長期的にはDB容量・パフォーマンスの両面で負債になりやすい点には注意が必要です。

---

DBの断片化（ディビジョン）とは何か

リビジョンや不要データを削除しても、DBファイルのサイズがすぐに減らないのは、MySQL（InnoDB）の仕様によるものです。

InnoDBでは、レコードを削除すると論理的には消えますが、確保していた領域は空き領域としてDB内部に残り、OSレベルでは解放されません。この空き領域がテーブル内に点在した状態を、DBの**断片化（フラグメンテーション／ディビジョン）**と呼びます。

断片化が進むと、

• DBファイルサイズが減らない
• クエリ性能が低下する
• バックアップやリストアに時間がかかる

といった問題が発生します。リビジョンを大量に削除した後ほど、断片化対策が重要になります。

---

WordPressのリビジョン機能の設定方法

リビジョン機能は、wp-config.php で挙動を制御できます。運用方針に応じて、必ず設定を見直しておきましょう。

---

リビジョン数を制限する（推奨）

最も現実的なのが「リビジョン数の上限を設ける」方法です。

define('WP_POST_REVISIONS', 5);

この例では、各投稿につき最大5件までしかリビジョンが保存されません。古いリビジョンは自動的に削除されるため、DBの肥大化を防ぎやすくなります。

---

リビジョン機能を完全に無効化する

履歴管理が不要なサイトの場合は、リビジョンを完全に無効化する選択肢もあります。

define('WP_POST_REVISIONS', false);

ただし、誤操作時に元に戻せなくなるため、運用体制を考慮して判断する必要があります。

---

自動保存（autosave）の間隔を調整する

リビジョンとは別に、自動保存（autosave）もDB更新頻度に影響します。

define('AUTOSAVE_INTERVAL', 300);

デフォルトは60秒ですが、更新頻度が高い場合は間隔を延ばすことでDB負荷を軽減できます。

---

既に溜まってしまったリビジョンを削除する方法

ここからは、すでにDB内に大量に蓄積してしまったリビジョンを整理する手順を説明します。ここではあらかじめ流れを明確にしておきます。

この作業は、次の2段階で必ずセットで行います。

1. リビジョンデータそのものをDBから削除する
2. 削除後に残るDBの断片化（ディビジョン）を解消する

リビジョン削除だけ、あるいはDB最適化だけを行っても十分な効果は得られません。それぞれの役割を理解したうえで、順番どおりに実施することが重要です。

---

【ステップ1】リビジョンデータをDBから削除する

まず行うのは、リビジョンという不要データそのものをDBから取り除く作業です。これを行わなければ、後述するDB最適化を実施しても意味がありません。

リビジョン削除は「SQLで直接削除」が基本

リビジョン削除は、プラグインを利用すればWordPressの管理画面から実行することも可能です。小規模サイトやDB容量がまだ小さい場合であれば、管理画面からの削除でも大きな問題になることは少ないでしょう。

しかし、すでにDBが肥大化している状態では注意が必要です。プラグインによる削除処理はPHPを経由してSQLを実行するため、データ量が多い環境では処理が途中で止まったり、完了状態が分かりにくくなるケースがあります。

そのため、DB容量が大きい場合や確実性を重視する場合は、WordPressやPHPを介さず、SQLを直接実行してリビジョンを削除する方法を基本と考えるのが安全です。

リビジョン削除に使用するSQLと実行環境

リビジョン削除に使用するSQL自体は共通ですが、どの環境で実行するかによって安定性が大きく変わります。

• CLI（SSH）から実行
  • MySQLクライアントを直接使用
  • PHPの制限を受けない
  • 大規模DB・本番環境向け
• phpMyAdminなどのGUIツールから実行
  • ブラウザ操作で手軽
  • PHPを経由するため大容量DBでは不安定
  • 小規模サイト・検証環境向け

サイト規模やDB容量に応じて、適切な実行方法を選択してください。

リビジョンを削除するSQL例

DELETE FROM wp_posts WHERE post_type = 'revision';

あわせて、リビジョン削除によって孤立した不要なメタデータも整理します。

DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

※ 実行前には必ずDBのバックアップを取得してください。

---

【ステップ2】削除後にDB最適化を行い、断片化を解消する

リビジョン削除によって論理的にはデータ量は減りますが、DBファイルのサイズはすぐには減りません。これはMySQL（InnoDB）の仕様により、削除された領域が空き領域としてDB内部に残るためです。

この状態を解消するために行うのが、DB最適化、つまり断片化（ディビジョン）の解消です。

プラグインによるDB最適化の注意点

WP-Optimize などのDB最適化プラグインは手軽に実行できる反面、以下の点に注意が必要です。

• DB容量が大きいとPHPの実行時間制限に引っかかりやすい
• ブラウザ経由のため、通信断や管理画面フリーズの影響を受けやすい
• 処理結果が分かりにくい場合がある

そのため、数GBを超えるDBや本番環境では慎重な判断が必要です。

CLI（SSH）によるDB最適化と注意点

DB容量が大きい場合や、確実に断片化を解消したい場合は、CLI（SSH）でサーバーにログインし、MySQLクライアントからSQLを実行する方法が最も安全です。

OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;

この OPTIMIZE TABLE はSQLコマンドであり、WordPressやPHPを経由せずに直接DBへ作用します。そのため、大容量DBでも安定して断片化を解消できます。

補足：InnoDBで表示されるメッセージについて

OPTIMIZE TABLE を実行した際、環境によっては次のようなメッセージが表示されることがあります。

Table does not support optimize, doing recreate + analyze instead

一見すると「最適化できない」「失敗した」と感じますが、これはエラーではありません。InnoDBはMyISAMのように「未使用領域だけをその場で詰め直す」タイプの OPTIMIZE TABLE を直接サポートしていないため、MySQLが自動的に同等の効果を得るための別手段に切り替えている、という意味になります。

具体的には、内部的に次のような処理が行われます。

• テーブルを作り直す（recreate：実質的な再構築）
• インデックスを作り直す（再生成）
• 統計情報を更新する（analyze：オプティマイザ向けの情報更新）

この「再構築＋解析」によって、削除後に残っていた空き領域が整理され、断片化（ディビジョン）が解消されます。つまり、表示されているのは「最適化できなかった」ではなく、

• InnoDBでは最適化＝再構築で実現する
• その手順に切り替えて実行した

という“実行方式の案内”です。

ただし、再構築が走るということは、運用面でいくつか注意点もあります。

• 大きなテーブルほど処理時間が長くなる
• 一時的にI/O負荷が上がる
• テーブルのサイズやMySQLの設定によってはロックや待ちが発生することがある

そのため、アクセスが集中する時間帯を避け、必ずバックアップを取ったうえで実行するのが安全です。

---

リビジョン対策とDB最適化は必ずセットで行う

リビジョンによるDB肥大化への対策は、

• 今後リビジョンを増やさないための設定見直し
• 既に蓄積したリビジョンデータの削除
• 削除後に残る断片化を解消するDB最適化

この3つを一連の作業フローとして実施することが重要です。どれか一つだけを行っても、DB容量やパフォーマンスの問題は根本的には解決しません。

まとめ：リビジョン管理と断片化対策がDB健全性を守る

WordPressのリビジョン機能は便利である一方、無制限に有効化されたまま運用すると、DB肥大化の大きな要因になります。特に更新頻度の高いサイトでは、リビジョンが積み重なることで、DB容量やパフォーマンス、バックアップ作業にまで影響が及びます。そのため、サイトの運用方針に合わせてリビジョン数を制限、もしくは無効化することが重要です。

さらに、不要データを削除した後には、必ずDBの最適化を行い、断片化を解消する必要があります。プラグインによる手軽な方法と、CLIによる確実な方法の特性と注意点を理解し、サイト規模に応じた適切な手段を選択することが、WordPressを長く安定して運用するための基本と言えるでしょう。