WordPressデータベースを最適化する方法

WordPressのデータベース最適化とは、不要になったリビジョン・ゴミ箱・期限切れTransientなどを整理し、必要に応じてデータベーステーブルの無駄な領域を整理する作業です。

ただし、「最適化ボタンを押せば必ず表示速度が上がる」というものではありません。まず不要データを減らし、そのうえで本当にテーブル最適化が必要かを判断するのが安全です。

30秒でわかる結論

WordPressデータベースの最適化とは？

WordPressでは、記事本文、固定ページ、ユーザー情報、各種設定、コメント、リビジョン、プラグイン設定など多くの情報をMySQLまたはMariaDBへ保存します。

長期間運営すると、使わなくなったデータや一時データが蓄積することがあります。そこで不要データを整理し、必要に応じてデータベーステーブルを再編成するのが「データベース最適化」です。

この2つを同じものとして扱わないことが重要です。 不要データを削除しても、必ずテーブル最適化が必要になるわけではありません。

データベースが大きくなる主な原因

原因	保存されるもの	整理判断
リビジョン	記事・固定ページの過去版	必要数を残して整理可能
ゴミ箱	削除前の投稿・コメント	不要なら削除可能
スパムコメント	迷惑コメント	確認後削除可能
Transient	一時的なキャッシュ値	期限切れは整理候補
プラグイン設定	独自テーブル・options等	慎重に判断
postmeta	記事にひも付く追加情報	手動削除は慎重

最適化前に必ずバックアップする

データベース最適化で最も重要なのは、作業前のバックアップです。

データベースには記事本文だけでなく、サイトURL、ユーザー情報、テーマ・プラグイン設定、ウィジェット、各種オプションなどが保存されています。 誤って削除すると、サイト表示や管理画面に影響する可能性があります。

最適化手順1．リビジョンを整理する

WordPressのリビジョンは、記事や固定ページを更新したときの過去版をデータベースへ保存する仕組みです。 誤って編集したときに以前の内容へ戻せるため便利ですが、長期間運営すると件数が増えることがあります。

ただし、リビジョンをすべて削除する必要はありません。 最近の数世代を残しておけば、編集ミスから戻せるメリットを維持できます。

今後の保存数を制限したい場合は、wp-config.phpでWP_POST_REVISIONSを設定する方法もあります。ただし、現在保存済みのリビジョンを自動的に一括削除する機能ではありません。

最適化手順2．ゴミ箱・スパムコメントを整理する

削除した投稿・固定ページ・コメントは、一定期間ゴミ箱へ残る場合があります。 スパム判定されたコメントもデータベースへ保存されます。

復元する予定がなければ削除できます。 ただし会社サイトなどで過去ページを一時的にゴミ箱へ移している場合は、担当者へ確認してから完全削除してください。

最適化手順3．期限切れTransientを整理する

Transientは、WordPressやプラグインが一時データを保存するための仕組みです。 外部APIの結果や計算済みデータなどを一定時間保存し、毎回同じ処理を行わないために使われます。

永続オブジェクトキャッシュを使っていない一般的なWordPressでは、Transientがwp_optionsテーブルなどへ保存されます。

期限切れTransientは削除候補です。 WP-CLIが使える環境では、期限切れだけを削除するコマンドも用意されています。

最適化手順4．使わなくなったプラグインのデータを確認する

プラグインを削除しても、そのプラグインが作成した設定値や独自テーブルが残る場合があります。

ただし、これらを手動で削除するのは慎重に行う必要があります。 テーブル名だけを見て不要と判断すると、別プラグインやテーマが利用しているデータを消す可能性があります。

最適化手順5．データベーステーブルを最適化する

不要データを大量に削除した後などは、MySQLのOPTIMIZE TABLEによってテーブルの格納状態を再編できる場合があります。

MySQL公式では、OPTIMIZE TABLEはテーブルデータとインデックスの物理格納を再編し、未使用領域を減らしたりI/O効率を改善したりする処理として説明されています。

OPTIMIZE TABLEでは何が起きる？

WordPressでよく使われるInnoDBでは、OPTIMIZE TABLE実行時にテーブル再構築に相当する処理が行われます。 MySQLの現行ドキュメントでは、InnoDBに対するOPTIMIZE TABLEはALTER TABLE … FORCEへマッピングされると説明されています。

大きなテーブルでは時間がかかることがあり、処理中の負荷や一時的なロックも考慮する必要があります。

サイト規模	考え方
小規模ブログ	頻繁な実行は不要
長期運営サイト	大量削除後に検討
EC・会員サイト	本番負荷を考慮して慎重に実施
大規模DB	管理者・サーバー会社と相談

WordPressでデータベースを最適化する方法

実際の方法は主に3つあります。

方法1．レンタルサーバーの管理機能を使う

レンタルサーバーによっては、phpMyAdminなどのデータベース管理ツールを提供しています。 テーブル最適化機能を利用できる場合があります。

ただし、操作画面や権限はサービスごとに異なるため、公式マニュアルを優先してください。

方法2．WordPressの最適化プラグインを使う

データベース最適化プラグインには、リビジョン、ゴミ箱、スパム、Transientなどを整理できるものがあります。

方法3．WP-CLIを使う

SSHとWP-CLIが利用できる環境では、公式WP-CLIのデータベースコマンドを使えます。

これはデータベースを最適化するコマンドです。 また、期限切れTransientだけを削除するコマンドもあります。

プラグインで削除しやすいもの・慎重に扱うもの

データ	初心者の判断
古いリビジョン	必要数を残して削除可
ゴミ箱	復元不要なら削除可
スパムコメント	確認後削除可
期限切れTransient	削除候補
孤立postmeta	慎重
options内の不明データ	手動削除しない
プラグイン独自テーブル	作成元確認後に判断

最適化するとWordPressは速くなる？

速くなる場合はありますが、必ず体感できるとは限りません。

たとえば、wp_optionsが異常に肥大化している、大量リビジョンや不要データがある、DBアクセスがボトルネックになっている、といった場合には改善につながる可能性があります。

一方、画像が巨大、テーマやプラグインのPHP処理が重い、外部API待ちが長い、ページキャッシュが使われていない場合は、DBを少し整理しても表示速度はほとんど変わらないことがあります。

データベース容量はどれくらいなら問題？

「100MBを超えたら危険」「1GBなら重い」という固定基準はありません。

記事数、ECの商品数、注文履歴、会員数、アクセス解析データ、プラグイン構成によって正常な容量は大きく変わります。

容量全体よりも、どのテーブルが増えているかを見る方が原因を判断しやすくなります。

特にwp_optionsが大きいときの注意

wp_optionsにはWordPress本体、テーマ、プラグインの各種設定が保存されます。 一部の値はページ表示時に自動読み込みされるため、不要な大容量データが大量に存在すると負荷へ影響する可能性があります。

ただし、wp_optionsは重要な設定を多数含むため、手動で「大きいものから消す」という方法は危険です。

リビジョンを0にすれば最適化になる？

おすすめしません。

リビジョンは編集ミスから復元するための重要な機能です。 WordPress公式では保存数を制限できますが、0に近づけるほど復元できる履歴も減ります。

自動最適化は設定した方がよい？

ゴミ箱や期限切れTransientなど、対象が明確なものを定期的に整理する機能は便利です。

一方で、毎日すべてのテーブルをOPTIMIZEしたり、孤立データを自動判定で削除したりする設定は、サイトによっては不要です。

最適化する頻度は？

一般的な個人ブログや会社サイトでは、毎日データベース最適化を行う必要はありません。

サイト	確認の目安
小規模ブログ	数か月ごと、または容量増加時
会社サイト	保守作業時に確認
更新頻度が高いサイト	DB増加状況を見て判断
EC・会員サイト	定期監視し慎重に実施

固定スケジュールより、「DBサイズが急増した」「大量削除を行った」「管理画面が重くなった」といった変化をきっかけに確認する方が合理的です。

最適化しても重いときは何を見る？

DB最適化は高速化の一部です。 原因がデータベースにない場合は、別の場所を改善する必要があります。

どんなサイトで最適化が必要？

やってはいけない最適化

• バックアップなしでDBを削除する
• 意味不明なoptionsをまとめて削除する
• プラグイン独自テーブルを名前だけで不要と判断する
• 本番ECサイトで大量削除をいきなり実行する
• 毎日OPTIMIZE TABLEを実行すれば高速になると考える
• 複数の最適化プラグインを同時に動かす
• 速度低下の原因を確認せずDBだけ触る

教科書判定

FAQ

まとめ