WordPressデータベースを高速化する方法：4つのチェックリスト

WordPressの管理画面の読み込みに5秒もかかるべきではありません。もしそうなら、問題はホスティングプランや画像にあるのではなく、データベースにある可能性があります。

あなたのデータベースには、期限切れの一時データ、数千もの投稿リビジョン、数年前に削除したプラグインの自動ロードデータなど、長年蓄積されたジャンクが静かに溜まっています。

そのほとんどはwp-adminでは見えず、訪問者が見るものには影響しません。しかし、積み重なると、最終的にはすべてを遅くします。

私は、1つのプラグインがページ読み込みごとに80件のデータベースクエリをトリガーしていたサイトを診断したことがあります。ホストは問題ありませんでした。キャッシュは正しく設定されていました。実際のデータベースの問題が解決されるまで、何も効果はありませんでした。

この記事では、ボトルネックを特定し、データベースの肥大化をクリーンアップし、クリーンアップ後も残る重いテーブルを修正し、そもそもWordPressがデータベースにアクセスする頻度を減らす方法を説明します。

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

• 遅い管理画面は、ホストや画像ではなく、ほぼ常にデータベースを示しています。管理画面はページキャッシュをバイパスするため、最も明確なシグナルとなります。
• 投稿リビジョン、期限切れの一時データ、孤立したプラグインデータ、肥大化した自動ロードオプションが最も一般的な原因であり、wp-adminで表示されやすい傾向があります。
• Query Monitor（無料）は、何かを削除する前に、どのプラグインまたはクエリがボトルネックになっているかを特定します。
• DB Optimizerは、データベースの健全性を5つのカテゴリで評価し、クリーンアップを確認する前に削除される内容の完全なプレビューを表示します。
• wp_optionsの自動ロードデータは1MB未満に保つべきです。それを超えると、すべてのページ読み込みで不要な負荷がかかります。
• RedisまたはMemcachedを使用したオブジェクトキャッシュは、ページキャッシュでは対応できない遅い管理画面を大幅に改善できます。
• すべてのメジャーバックアップまたは移行の前にクリーンアップを実行してください。データベースが小さいほど、転送が速くなり、バックアップファイルも小さくなります。

目次

WordPressデータベースが遅くなる原因は何ですか？

修正に入る前に、何に対処しているのかを知っておくと役立ちます。WordPressデータベースは予測可能な理由で遅くなり、ほとんどのサイトでは複数の原因が同時に発生しています。

投稿リビジョン

投稿を保存または更新するたびに、WordPressは新しいコピーを作成します。アクティブなサイトでは、1つの投稿に無期限にデータベースに保存されている多数のリビジョンコピーが存在する可能性があります。

これらは訪問者には見えませんが、投稿テーブルに対するすべてのクエリに負荷を加えます。

期限切れの一時データ

プラグインは、外部API呼び出しやスケジュールされたタスクからのデータを一時的にキャッシュするためにトランジェントを使用します。これらは自動的に期限切れになり、削除されるはずです。

多くの場合、それらはそうならず、期限切れのレコードは目的を果たすずっと後まで wp_options テーブルに積み重なります。

孤立した行と残りのプラグインテーブル

プラグインが削除されると、そのデータは通常、カスタムフィールド、ユーザーメタデータ、投稿メタデータ、そして時にはプラグインにちなんで名付けられたデータベーステーブル全体が残ります。長年、数十個のプラグインを切り替えてきたサイトには、それぞれのゴーストデータが残っています。

wp_optionsの自動ロードデータ

autoload = yesとしてフラグ付けされたオプションは、WordPressが何かをレンダリングする前に、すべてのページリクエストでロードされます。このフラグを乱用するプラグインは、そのプラグインとは関係のないページであっても、すべてのページロードに重みを追加します。

自動ロードされるデータの合計は1MB未満に保つべきです。遅いサイトの多くは5MB以上に達しています。

テーブルの断片化

行が削除されると、MySQLはそれらが占めていたスペースを自動的に回復しません。時間が経つにつれて、テーブルは断片化し、MySQLはそれらを読み取るために一生懸命働く必要があります。

これが、「テーブルの最適化」コマンドを実行すると、データ自体がきれいに見えても、物事がスピードアップする理由です。

遅いまたは過剰なプラグインクエリ

一部のプラグインは単純に貧弱に書かれています。それらは単一のページロードで数十のクエリを実行するか、インデックスが付けられていない列をクエリして、MySQLに正しいレコードにジャンプする代わりに、テーブル全体を行ごとにスキャンするように強制します。

遅いWordPressデータベースを修正する方法

遅いWordPressデータベースを修正するには、何が遅いのかを見つけ、原因となっている不要なものを削除し、クリーンアップを生き残ったテーブルを修正し、次にデータベースがクエリされる頻度を減らす必要があります。

実行する内容は以下の通りです。

• ステップ1：データベースを遅くしているものを特定する：無料のQuery Monitorプラグインを使用して、サイトで実行されているすべてのクエリ、各クエリにかかる時間、およびどのプラグインがそれをトリガーしたかを確認します。
• ステップ2：データベースの肥大化をクリーンアップする：DB Optimizerを使用して、5つのヘルスカテゴリにわたってデータベースをスコアリングし、削除されるものを正確にプレビューし、組み込みの保持しきい値で安全にクリーンアップします。
• ステップ3：重いテーブルを処理する：wp_optionsの自動ロード肥大化を修正し、関連する場合はWooCommerce HPOSを有効にし、InnoDBであるべきMyISAMテーブルを確認し、phpMyAdminなしでテーブルオーバーヘッドを最適化します。
• ステップ4：WordPressがデータベースをクエリする頻度を減らす：まだ行っていない場合はページキャッシュを追加し、次にRedisまたはMemcachedでオブジェクトキャッシュを有効にして、ページキャッシュが到達できない管理画面の遅さを修正します。

ステップ1：データベースを遅くしているものを特定する

Query Monitorは、現在のページで実行されているすべてのデータベースクエリ、各クエリにかかる時間、およびそれをトリガーしたプラグインまたはテーマを示す無料のプラグインです。WordPressプラグインディレクトリからインストールし、他のプラグインと同様にアクティブ化します。

アクティブになると、管理バーに新しい項目が表示され、現在いる画面の合計クエリ数とページロード時間が表示されます。それをクリックして完全なパネルを開きます。

データベースクエリタブに移動します。0.05秒以上かかるクエリと、異常に多数の呼び出しを生成しているプラグインを探します。

Query Monitorは、責任のあるプラグインまたはテーマを直接名前で示しているため、推測する必要はありません。

1つのプラグインがページあたり40以上のクエリを生成しているか、クエリが常に0.05秒を超えている場合、それがボトルネックです。それを無効にして、再度テストしてください。

特定のクエリが際立っていない場合、問題は特定の悪質なアクターではなく、データベース全体に分散した一般的な肥大化です。ステップ2に進んでください。

続行する前に確認すべきことの1つ：クエリモニターは現在のページの動作のみを表示します。管理画面、WooCommerceの商品ページ（もしあれば）、標準の投稿で実行してください。

遅延はページ固有であることが多く、チェックアウトページのクエリの問題は、管理画面を見ている間は表示されません。

ステップ2：データベースの肥大化をクリーンアップする

ほとんどの人は、何を安全に削除できるかわからないため、データベースのクリーンアップをスキップします。その躊躇はもっともです。データベースで間違ったものを削除しても元に戻すことはできません。

DB Optimizerは、削除する前にデータベースに何があるかを正確に表示することで、その問題を解決します。最初に表示されるのは、0から100までの健全性スコアです。

これは5つのカテゴリに分類されます：テーブルオーバーヘッド、トランジェント、リビジョン、オートロードサイズ、ゴミ箱アイテム。それぞれにプログレスバーと色分けされた評価が付けられます。

緑は、そのカテゴリが良好な状態であることを意味します。黄色は、注意が必要であることを意味します。赤は、スコアを下げていることを意味します。いつでもスコアを更新ボタンをクリックして更新してください。

スコアを下げているものがわかったら、クリーンアップタブに移動します。上部にある概要バーには、クリーンアップ可能なアイテムの数と、データベース全体で回復可能な合計スペースが表示されます。

その下には、各クリーンアップタイプ（投稿とページ、コメント、トランジェントとキャッシュ）にアイテム数と推定サイズが表示されます。削除される前に、何に対処しているかを正確に確認できます。

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

移行の準備をしていて、まっさらな状態にしたい場合は、短くしてください。機密性の高いサイトで作業していて、さらに注意を払いたい場合は、長くしてください。年齢に関係なくすべてをクリーンアップしたい場合は、0に設定してください。設定は自動的に保存されます。

クリーンアップ後、リビジョンが再び蓄積する前に制限するために、wp-config.phpファイルに1行追加してください。

define('WP_POST_REVISIONS', 3);

「これで、編集を終了します！」と表示されている行の上に挿入します。これにより、WordPressは今後、投稿ごとに3つのリビジョンのみを保持するように制限されます。

DB Optimizerは、既存のものを処理します。この行は、それが再び戻ってくるのを防ぎます。

ステップ3：重いテーブルを処理する

クリーンアップは不要なデータを削除しますが、徹底的なクリーンアップの後でも継続的な遅延を引き起こす2つの特定のテーブルがあります：wp_optionsとwp_postmeta。ここで使用されるデータベースのストレージエンジンも重要です。

wp_optionsの自動ロードデータ

DB Optimizerは、5つの健全性カテゴリの1つとしてオートロードサイズを表示します。クリーンアップを実行しても1MBを超えている場合、プラグインが実行ごとにオートロードオプションを積極的に書き込んでいることになります。クリーンアップは古いエントリを削除しますが、新しいエントリが追加されるのを防ぐことはできません。

Query Monitorタブを使用して現在オートロードされているものを確認し、どのプラグインが原因かを特定します。それを無効にするか、サポートチームに連絡することが解決策です。

Wp_postmeta

このテーブルにはカスタムフィールドデータが格納され、WooCommerceやACFを多用するサイトではすぐに大きくなります。

Query Monitorは、このテーブルへのクエリが継続的なボトルネックである場合、それをフラグ付けします。クエリレベルで修正するのは開発者の領域ですが、問題がそれであると知ることは戦いの半分です。

WooCommerceユーザー：HPOSを有効にする

WooCommerceを実行している場合は、WooCommerce » 設定 » 詳細設定 » 機能に移動し、High Performance Order Storageをオンにしてください。

これにより、注文データがwp_postmetaから専用の目的構築済みテーブルに移動されます。注文数が数百を超えるストアでは、注文クエリを劇的に高速化できます。

有効にした後、WooCommerceから既存の注文データを移行するように求められる場合があります。続行する前に移行を実行してください。

ストレージエンジン：MyISAM vs InnoDB

MyISAMは、すべての書き込み操作中にデータベーステーブル全体をロックするため、実質的な書き込み負荷の下ではキューイングが発生します。InnoDBは、書き込まれている特定の行のみをロックします。

WordPressはMySQL 5.7以降、InnoDBをデフォルトにしていますが、古いホスティング環境から移行されたサイトでは、MyISAMテーブルがまだ使用されている場合があります。

DB Optimizerのテーブルタブは、各テーブルのストレージエンジンを表示します。MyISAMテーブルが表示された場合、InnoDBに変換するのは1行のSQL変更ですが、開発者に依頼するか、ホストにコントロールパネル経由で処理できるか確認する価値があります。

テーブルのオーバーヘッド

DB Optimizerは、オーバーヘッドを抱えるテーブルをハイライトし、横に最適化ボタンを表示します。個別に処理するか、一度にすべてのオーバーヘッドをクリアできます。

クリーンアップ後に実行してください。行の削除がそもそもオーバーヘッドを作成する原因となるためです。

ステップ4：WordPressがデータベースにクエリする頻度を減らす

たとえクリーンで最適化されたデータベースであっても、すべてのページロードでクエリが実行されます。キャッシュレイヤーはこれらのクエリをインターセプトするため、データベースの全体的な作業量が少なくなります。

ページキャッシュはページの完全なHTML出力を保存するため、WordPressはそのリクエストに対してデータベースを完全にスキップします。

キャッシュプラグインがない場合は、まずそれらを追加してください。WP Rocket、W3 Total Cache、LiteSpeed Cacheはすべてこれを処理します。ページキャッシュは、フロントエンドの訪問者に対して最も影響力の大きい変更です。

オブジェクトキャッシュも有効にする必要があります。オブジェクトキャッシュは個々のデータベースクエリ結果をサーバーメモリに保存するため、繰り返し実行されるクエリはデータベースではなくキャッシュにヒットします。

管理画面のリクエスト、WooCommerceのチェックアウト、および完全にキャッシュできないページはすべて、これの恩恵を受けます。

ホストにRedisまたはMemcachedが利用可能か尋ねてください。多くのマネージドWordPressホストは、1つまたは両方を含んでいます。

Redisが利用可能な場合は、Redis Object Cacheプラグインをインストールし、ホストの接続手順に従ってください。プラグインは、正しく機能している場合に接続済みステータスを表示します。

ホストが実際にRedisサーバーを提供していない限り、Redis Object Cacheをインストールしないでください。アクティブな接続がないと、プラグインはエラーを発生させ、メリットはありません。

オプション：遅いデータベースを修正するためのWP-CLIコマンド

コマンドラインからWordPressを管理している場合、これらのコマンドはプラグインインターフェイスなしで上記のステップと同じことをカバーします。

wp db optimize

クリーンアップ後もオートロードサイズが高いまま

wp transient delete --expired

wp_optionsから期限切れの一時データをすべて削除します。

wp post delete $(wp post list --post_status=trash --format=ids)

現在ゴミ箱にあるすべての投稿を完全に削除します。

wp post delete $(wp post list --post_type='revision' --format=ids)

保存されているすべての投稿リビジョンを削除します。

これらのいずれかを実行する前に、Duplicatorでバックアップしてください。これらはプレビュー手順や確認プロンプトなしで即座に実行されます。

WP-CLIは、DB Optimizerが行うようなヘルススコアリング、保持しきい値、またはカテゴリごとのプレビューを提供しません。単に同じクリーンアップタスクへのより高速なパスを提供するだけです。

トラブルシューティング：データベースがまだ遅い場合

これらのすべての手順を試してもサイトがまだ遅い場合は、これらのシナリオのいずれかが原因である可能性が高いです。

Query Monitorに明らかな原因が表示されない

表示される内容：個々のクエリはすべて0.05秒未満ですが、ページは依然として遅く読み込まれます。

問題は、個々の遅いクエリではなく、クエリの総量である可能性があります。それぞれ0.01秒の200個のクエリでも、レンダリング前にデータベース時間に2秒かかります。

Query Monitorのサマリーバーを確認してください。標準ページでクエリの総数が50〜75を超えている場合は、調査する価値があります。

プラグインを1つずつ非アクティブ化し、各非アクティブ化後にページをリロードして、カウントが減少するのを確認します。最も大きな減少を引き起こしたプラグインが対象です。

Autoload Size Stays High After Cleanup

表示される内容：クリーンアップを実行した後でも、DB Optimizerのオートロードサイズが1MBを超えています。

クリーンアップは期限切れおよび孤立したオートロードエントリを削除しますが、プラグインが新しいエントリを書き込むのを停止することはできません。数値が常に増加し続ける場合は、リクエストごとに何かが積極的にオートロードプールに追加されています。

Query Monitorは、現在のページでオートロードされているすべてのオプションを表示します。認識できない、または積極的に使用していないプラグインのエントリを探し、それらのプラグインを1つずつ非アクティブ化してスコアを更新してください。

クリーンアップ後もWooCommerceのチェックアウトが遅い

表示される内容：クリーンアップ後、チェックアウトページが読み込まれるのに3〜5秒かかります。

HPOSが有効になっているが、データ移行が完了していない可能性があります。WooCommerce » Status » Toolsに移動し、Migrate order dataオプションを探してください。そこにある場合は、実行してください。

移行が不完全な場合、WordPressは古いテーブル構造と新しいテーブル構造の両方から同時に読み取るため、どちらか一方よりも遅くなります。

移行がすでに完了している場合、競合するプラグインがWooCommerceをレガシー注文テーブルに強制的に戻している可能性があります。プラグインを1つずつ無効にし、それぞれ後にチェックアウト速度をテストしてください。

オブジェクトキャッシュが接続済みと表示されても管理画面が遅い

表示される内容：Redis Object Cacheプラグインは「接続済み」と表示されますが、管理画面は依然として遅いです。

プラグインがリクエストごとにオブジェクトキャッシュをフラッシュしている可能性があり、それはキャッシュがあることの目的を無効にします。Query Monitorを開き、キャッシュを確認してください。キャッシュヒット率が80％未満の場合は、何かが積極的にフラッシュしています。

2つか3つのグループに分けてプラグインを無効化し、各グループの後に比率を確認して特定します。ヒット率が急上昇した場合、最後に無効化したグループに問題があります。

何も機能していません

4つのステップすべてを完了してもパフォーマンスが改善しない場合、問題はデータベース自体以外にある可能性が高いです。共有ホスティングでのMySQLメモリ不足は、サーバーがRAMの代わりにディスクスワッピングを使用するように強制するため、クリーンアップしても修正できません。

ホストに連絡し、MySQLメモリ割り当てと、サーバー側のスロークエリログが利用可能かどうかを具体的に尋ねてください。開発者がスロークエリログを確認することで、Query Monitorでは検出できない問題を特定できます。

よくある質問（FAQ）

あなたのデータベースは勝手にきれいになりません

あなたはほとんどのWordPressサイト所有者が決してしないことをしました：データベースのボトルネックを診断し、長年蓄積されたデータをクリーンアップし、永続的な遅延を引き起こす特定のテーブルに対処し、データベースが作業する必要がある頻度を減らしました。

今後、月に一度DB Optimizerのヘルスチェックを実行してください。データベースの肥大化は徐々に元に戻るので、月に一度のチェックで蓄積を防ぎます。

また、最適化はデータベースを永続的に変更することを覚えておいてください。開始前のバックアップは、修正可能な間違いと永続的な間違いの違いです。

150万以上のWordPressのプロフェッショナルがDuplicatorを使用してサイトのバックアップと移行を行っています。無料プランはサイト全体のバックアップをカバーし、セットアップには約2分かかります。クラウドストレージ、自動バックアップ、およびDuplicator Proで無料のDB Optimizerプラグインにアップグレードしてください！

このガイドがお役に立ったなら、これらの投稿もブックマークする価値があります。

• WordPressデータベースの最適化方法
• 私が自分で実行したWordPressデータベース修復手順
• WordPressデータベースメンテナンス：毎週、毎月、四半期ごとに行うべきこと
• WordPressデータベースのバックアップ方法
• 私が使用した中で最高のWordPressデータベース最適化プラグイン（および3つの代替案）