サイト所有者が見逃しがちなWordPressデータベースの警告サイン7選

サイトは読み込まれています。訪問者は不満を言っていません。wp-adminでエラーは発生していません。

しかし、データベースには数ヶ月、あるいは数年分の不要なデータが静かに蓄積されている可能性があります。

データベースの肥大化は、必ずしもフロントエンドに現れるわけではありません。訪問者にとって、データベースがスリムであろうと、数千件の投稿リビジョンを抱えていようと、ページの見かけは同じです。

問題は別のところで表面化します。バックアップの完了に倍の時間がかかる、移行が途中で停止する、あるいは管理画面がページ読み込みごとに遅く感じられる、といった具合です。

これは、他に問題なく管理されていたサイトでも見られました。何年もデータベースを確認していなかったため、移行しようとした瞬間にその影響が現れました。

これらの兆候は具体的で診断可能です。SQLクエリを実行したり、phpMyAdminを調べたりしなくても、データベースに注意が必要かどうかを知ることができます。ただ、何に注意すべきかを知る必要があるだけです。

WordPressデータベースの最適化が必要な主な兆候と、健全なデータベースがどのようなものかを示し、目標を設定できるようにします。

主なポイントは次のとおりです：

• データベースの肥大化は、特にキャッシュされたページでは、フロントエンドでは見えにくいことがあります。兆候は、ライブサイトではなく、バックアップサイズ、移行時間、管理画面の速度に現れることが多いです。
• 注意すべき兆候：管理画面の遅延、投稿保存エラー、「データベース待機中」の速度テストでの遅延、キャッシュされていないページの読み込み遅延、バックアップサイズの肥大化、移行の遅延、データベースサイズの不均衡。
• 約800KBから1MBを超えるオートロードデータは、サイトやキャッシュ設定によっては懸念事項となる可能性があります。まず確認すべきはwp_optionsテーブルです。
• アンインストールされたプラグインからの孤立したテーブルは、静かに蓄積され、何も有用なものを追加せずにデータベースサイズに貢献します。
• DB Optimizerは、5つのカテゴリにわたってデータベースの健全性を0から100のスコアで評価し、移行やバックアップの前に何に注意すべきかを正確に把握できます。
• 移行前にクリーンアップしましょう。後からではなく。データベースが小さいということは、バックアップが小さく、転送が速く、問題が発生した場合のデバッグが少なくて済むということです。

目次

WordPressデータベースに蓄積されるものとは？

WordPressは、実際のコンテンツとは無関係な驚くほどの量のデータを生成します。これはあなたのせいではありません。プラットフォームの仕組みです。

投稿リビジョン

投稿を保存または更新するたびに、WordPressはリビジョンを保存します。デフォルトでは、設定しない限り、組み込みの制限はありません。

50回編集した投稿には、データベースに50個のコピーが保存されています。アクティブなブログや複数のエディターが作業しているサイトでは、それらのコピーは急速に積み重なります。

期限切れの一時データとオートロードデータ

トランジェントは、プラグインがデータベースに保存する一時的なレコードです。APIレスポンス、キャッシュされたクエリ結果、一時的な設定などが該当します。

これらは、設定された期間が経過すると自動的に期限切れになるように設計されています。多くの場合、クリーンアップされるか、再度アクセスされるまでデータベースに残ります。

期限切れのトランジェントは、WordPressがサイト全体のオプションを保存する `wp_options` テーブルに蓄積される可能性があります。「autoload」としてフラグ付けされたものは、キャッシュされていないすべてのページリクエストで読み込まれます。

autoloadされたデータが800KBから1MB以上に増加すると、パフォーマンスの問題になる可能性があります。サイト上のすべてのページ読み込み（管理画面を含む）にオーバーヘッドが追加されます。

スパムコメント、ゴミ箱、孤立したメタデータ

投稿をゴミ箱に入れたり、コメントをスパムとしてマークしたりしても、データベースから削除されるわけではありません。完全に削除されるまで、そこに残ります。

非アクティブ化されたプラグインは、`wp_postmeta` および `wp_options` テーブルに行を残します。プラグインが削除されると、それらの行にはアタッチする親レコードがなくなります。

これらは孤立したメタデータと呼ばれ、プラグインを交換するたびに静かに蓄積されます。

テーブルオーバーヘッド

データベーステーブルから行が削除されると、MySQLはそのスペースを自動的に再利用しません。残されたギャップはオーバーヘッドと呼ばれます。

頻繁な書き込みを処理するテーブル（`wp_options` や `wp_postmeta` など）は、他のテーブルよりも早くオーバーヘッドを蓄積する可能性があります。オーバーヘッドは通常、何も壊しませんが、ディスクスペースを無駄にし、一部のメンテナンスタスクを非効率にする可能性があります。

WordPressデータベースの最適化が必要な7つの兆候

サイトの遅延は、ホスティングやプラグインのせいだと簡単に思われがちです。これらの兆候はそれよりも具体的です。それぞれが直接データベースを指しています。

• WordPress管理画面の遅延：ダッシュボードはページキャッシュをバイパスし、すべての読み込みでデータベースにクエリを発行します。肥大化した `wp_options` テーブルは、管理画面のすべてのページを遅くします。
• 投稿の保存エラー：書き込み失敗やテーブルの破損は、プラグインの競合のように見えますが、データベースにたどる保存エラーを生成します。
• スピードテストでの「データベース待機中」：GTmetrixはこれを具体的に特定します。サーバー応答が遅い高いTTFBは、ホストではなく、断片化されたテーブルを示しています。
• キャッシュされていないページの読み込みが遅い：ログインユーザー、エディター、WooCommerceのチェックアウトページはキャッシュをバイパスします。これらのフローが遅い場合、原因はデータベースである可能性が高いです。
• バックアップサイズの肥大化：バックアップサイズはデータベースサイズを直接反映します。不要なデータもすべて一緒にバックアップされます。
• 移行の遅延：肥大化したデータベースは、より大きな移行パッケージ、より遅いアップロード、そして転送中に問題が発生する可能性のあるものを増やします。
• 不均衡なデータベースサイズ：データベースがコンテンツ数に対して著しく大きい場合、孤立したテーブルや蓄積されたジャンクがその差を説明します。

WordPress管理画面が著しく遅い

これは通常、サイト所有者が最初に気づくことです。フロントエンドは問題ないように見えますが、ダッシュボード、投稿リスト、メディアライブラリの読み込みが遅くなります。

WordPressの管理画面はページキャッシュを完全にバイパスします。すべての管理画面はデータベースクエリに依存しています。

キャッシュされていないリクエストごとにWordPressが処理する必要のあるデータが増えます。wp_optionsが期限切れの一時保存データやプラグイン設定の残骸で肥大化すると、

オートロードされたデータが2MBを超えて増加したサイトでこれを見ました。wp-adminのすべてのページが応答するのに数秒かかりました。

解決策はホスティングのアップグレードではなく、データベースのクリーニングでした。

知っておくべきしきい値：オートロードされたデータが約800KBから1MBを超えると、警告サインであることがよくあります。

投稿の保存中にエラーが発生する

投稿保存中の断続的なエラーは、プラグインの競合のせいにするのが簡単です。多くの場合、データベースが実際の原因です。

破損、ロックの問題、またはサーバーの制約によって負荷がかかっているデータベースは、書き込み負荷の下で失敗し始める可能性があります。「本当にこれを実行しますか？」という一般的なプロンプト、白い画面、または保存されているように見えて保存されない投稿が表示されることがあります。

テーブルの破損（データベース操作が中断されたときに発生する可能性があります）は、同じ症状を引き起こします。

プラグインの競合を除外し、エラーが繰り返し発生する場合は、まずデータベースの健全性を確認してください。

スピードテストツールが「データベースを待機中」の遅延を示す

GTmetrixのようなツールは、ページ読み込み中に時間がどこで費やされているかを示します。

GTmetrixでは、ウォーターフォールチャートの紫色のバーは「待機時間」を表します。これは、ブラウザがリクエストを送信してからサーバーから最初のバイトを受信するまでの時間です。

長い紫色のバーはサーバー側の処理が遅いことを示しています。その処理にはデータベースクエリが含まれます。

断片化されたテーブルのスキャンに通常より時間がかかると、10ミリ秒未満で実行されるはずのクエリが積み重なり始めます。紫色のバーが長くなります。

TTFB（Time to First Byte、ブラウザリクエストと応答の最初のバイトまでの時間）が高く、サーバーの応答時間が遅いことは、データベースの注意が必要であることを示す最も明確な測定可能な信号の1つです。

キャッシュされていないリクエストでのページ読み込みが遅い

キャッシュは、ほとんどの訪問者からデータベースの問題を隠します。毎回データベースに問い合わせる代わりに、保存されたページのコピーを提供します。しかし、キャッシュはすべての人をカバーするわけではありません。

管理者ユーザー、エディター、ログインメンバーは、ページキャッシュを完全にバイパスします。WooCommerceのカートページとチェックアウトページも通常はバイパスします。これらのフローが遅いと感じる場合は、データベースが原因である可能性が高いです。

バックアップサイズが想定より大きい

バックアップサイズはデータベースサイズの直接的な反映です。デッドウェイトは他のすべてと一緒にバックアップされます。

100,000件の投稿リビジョンと50,000件の一時保存データを抱えるデータベースは、すべてのバックアップに実際のメガバイトを追加します。これは、転送時間の延長、消費されるクラウドストレージの増加、および復元が必要になった場合の復元の遅延を意味します。

バックアップはバックグラウンドで実行されるため、ほとんどの人はこれに気づきません。バックアップがタイムアウトした場合や、復元に予想よりも1時間長くかかった場合にのみ、それを感じます。

移行に予想以上の時間がかかる

WordPressサイトを移行すると、データベース全体が一緒に移動します。すべての孤立した行、期限切れの一時保存データ、およびリビジョンのコピーが移動します。

データベースが肥大化すると、移行パッケージが大きくなります。これは、アップロードが遅くなり、転送中に問題が発生する可能性が高まり、移行が失敗した場合にデバッグがより困難になることを意味します。

正しい順序は、まずデータベースをクリーンアップし、次にバックアップを作成し、最後に移行することです。

DB Optimizerは、この移行前のワークフローのために特別に構築されています。ヘルススコアを確認し、クリーンアップが必要なものをクリーンアップしてから移動してください。

データベースに孤立したテーブルがある、またはサイズが不均衡である

独自のデータベーステーブルを作成するすべてのプラグインは、開発者が明示的にクリーンアップコードを作成しない限り、アンインストール時にそれらをそのまま残します。

数年前に削除したプラグインのテーブルが、データベースに残っている可能性があります。これらはスペースを占有し、テーブルリストをスキャンするすべてのクエリに不要な情報をもたらします。

データベースが500MBで、投稿が300件しかない場合、孤立したテーブルや蓄積されたジャンクがその差を説明している可能性があります。

ほとんどのホスティングダッシュボードには、データベースサイズが表示されます。最近確認していない場合は、確認する価値があります。

健全なデータベースとは

適切にメンテナンスされたWordPressデータベースは次のようになります：

• オートロードデータは約800KBから1MB、サイトとキャッシュ設定によって異なります
• 最近のクリーンアップ後、テーブルオーバーヘッドはゼロまたはゼロに近い
• トランジェントはクリアされるか、予想通り期限切れになる
• 投稿リビジョンは制限されるか、定期的に削除される
• 無効化されたプラグインからの残存テーブルがない

ほとんどのサイト所有者は、SQLクエリを実行したりphpMyAdminを調べたりせずに、これらのことを確認する方法がありません。それがDB Optimizerが埋めるギャップです。

DB Optimizerは、データベースに0から100までのヘルススコアを与えるプラグインです。テーブルオーバーヘッド、トランジェント、リビジョン、オートロードサイズ、ゴミ箱アイテムの5つのカテゴリを評価します。

各カテゴリには独自のプログレスバーと色分けされた評価があります。緑は良好な状態であることを意味します。黄色は注意が必要であることを意味します。赤はクリーンアップの時間であることを意味します。

クリーンアップタブでデータベース全体をまとめて最適化します。DB Optimizerは、投稿リビジョン、スパムコメント、トランジェント、トラックバック、その他の不要なデータをクリーンアップします。

これにより、データベースメンテナンスは、実際に管理できる簡単なタスクに変わります。

次の移行前にデータベースの健全性を確認する方法

移行を計画している場合は、データベースの健全性を確認するのに最適な時期です。転送に2倍の時間がかかった後ではありません。

DB Optimizerを開き、ヘルススコアを確認します。緑、黄色、赤のカテゴリを確認します。これにより、何も触る前に問題がある場所がわかります。

クリーンアップタブに移動します。何かを実行する前に、DB Optimizerは、クリーンアップ可能なアイテムの総数と、データベース全体で回復可能なスペースを表示します。何をクリーンアップし、何をそのままにするかを決定します。

保持しきい値を設定します。デフォルトは7日間で、これは、選択したクリーンアップタイプに関係なく、過去1週間に作成されたものはすべて対象外であることを意味します。

慎重に行う場合は、値を高く設定します。移行前にクリーンな状態にしたい場合は、値を低く設定します。

DB Optimizerは、実行前に各クリーンアップタイプのアイテム数と推定サイズを表示します。リストを確認し、保持したいものをすべて選択解除し、準備ができたら確認します。

DB OptimizerはDuplicatorを自動的に検出し、クリーンアップコントロールのすぐ隣にバックアップを作成するための直接リンクを配置します。重要なものを失いたくないので、クリックしてください。

データベースがクリーンであるということは、バックアップが小さくなり、転送が速くなり、問題が発生した場合に確認する量が少なくなることを意味します。

よくある質問（FAQ）

肥大化したデータベースは自己修復しない

この記事で取り上げているパフォーマンスの問題は現実のものですが、フロントエンドではなく、バックアップサイズ、移行時間、管理画面の応答速度に現れます。だからこそ、無視されるのです。

コストは後から現れます。本来20分で終わるはずの移行に2時間かかります。ファイルが大きくなりすぎて、バックアップが転送中に失敗します。投稿の保存でエラーが発生し始め、データベースのクリーンアップが必要だったのに、プラグインの競合を除外するのに午後を費やします。

データベースのメンテナンスは、結果が明らかになるまで延期されがちなため、無期限に延期しやすいです。

インストールする前に、今すぐ実行する価値のあるチェックが1つあります。ホスティングダッシュボードまたはphpMyAdminを開き、wp_optionsテーブルのサイズを確認してください。通常のWordPressサイトでは、3〜5MB未満であるはずです。

10MB以上の場合、autoloadedデータがほぼ間違いなく問題です。その単一のテーブルは、肥大化すると、キャッシュされているかどうかにかかわらず、サイト全体のすべてのページ読み込みにオーバーヘッドを追加します。これは、データベースに修正する価値のある問題があるかどうかを大まかに把握するための最も簡単な方法です。

DB Optimizerは、より完全な画像を表示します。データベースの健全性スコア、実行前にクリーニングできるものの完全なプレビュー、および最近のデータを自動的に制限外に保持する設定可能な保持しきい値を提供します。

DB Optimizerは、WP Media Cleanup、Activity Log、Duplicator Proと共に、Duplicator Eliteプランに含まれています。WordPressサイトを健全に保ち、バックアップし、必要に応じて移動できるようにするための4つのツールです。

この記事を読んでデータベースの健全性について考えさせられたなら、次にこれらのガイドを読む価値があります。

• WordPressデータベースの最適化方法
• 私が自分で実行したWordPressデータベース修復手順（開発者不要）
• WordPressデータベースメンテナンス：毎週、毎月、四半期ごとに行うべきこと
• WordPressデータベースのバックアップ方法（完全ガイド）
• WordPressデータベースの復元方法（3つの方法）
• 簡単なデータ管理のためのWordPressデータベースプラグイン13選