15分でWordPressデータベースの健全性チェックを実行する方法
Joella Dunn
Joella Dunn
John Turner
ジョン・ターナー
WordPressにはサイトヘルスと呼ばれるツールが付属しています。ほとんどの人はデータベースの健全性を素早く確認するためにそれを使用しますが、何もクリーンアップすることはできません。
サイトヘルスは完全なデータベース監査ツールではありません。データベースサイズ、サーバー/クライアントのバージョンと文字セットを報告し、オートロードオプションの数と合計サイズをチェックします。リビジョン、テーブルオーバーヘッド、トランジェント残渣、またはプラグインテーブルは監査しません。
この記事では、実際のWordPressデータベースの健全性チェックを実行する方法、各数値がどのようになるべきか、そして何に対処すべきかを紹介します。所要時間は約15分です。
終了時には、5つの記録された数値、それぞれの評価、そして再度チェックする日付が得られます。
クイックテイクアウェイ:
- WordPressにはサイトヘルスというツールがありますが、包括的なデータベースの健全性チェックは提供していません。サイズ、バージョン、文字セットを報告しますが、内部に何があるかについてはほとんど測定しません。
- サイトヘルスは、約30秒で無料のサイズベースラインを提供します。DB Optimizerの0から100のスコアは、5つの指標のうちどれが問題を引き起こしているかを示します。
- 健全なオートロードは通常800KB未満、wp_optionsは一般的なサイトで3〜5MB未満です。これらの数値を過ぎると、対処する価値があります。
- リビジョンはデフォルトで無制限なので、wp-config.phpでWP_POST_REVISIONSを設定しない限り、そのメトリックは自動的に補充されます。
目次
WordPressデータベースのヘルスチェックは何をカバーしますか？
データベースの健全性チェックはサイズチェックではありません。サイズだけではほとんど何もわかりません。
10年分の実際の注文を保持する500MBのWooCommerceデータベースは、行の4分の3が投稿リビジョンである60MBのブログよりも状態が良い場合があります。
測定しているのは構成です。このデータベースのどれだけが失われるコンテンツで、どれだけが残骸なのか？
実際の健全性チェックでカバーされる内容は次のとおりです。
- 合計サイズと成長率。数値自体よりも、チェック間でどれだけ速く増加しているかが重要です。静かな四半期で40％増加したデータベースは、何かを物語っています。
- テーブルオーバーヘッド。削除された行が残したスペースで、MySQLがまだ回収していないものです。テーブル内のデッドエアです。
- オートロードサイズ。WordPressがページリクエストごとに読み込むオプションで、ページが必要かどうかに関係なく読み込まれます。これはパフォーマンスに最も直接影響するメトリックです。
- 行のジャンク。投稿リビジョン、自動下書き、ゴミ箱に入れられた投稿、スパムコメント、期限切れの一時データ、ピンバック、トラックバック、キャッシュされたoEmbed応答。これらすべてがデフォルトで蓄積され、自分でクリアされるものはありません。
- 孤立したテーブルとメタデータ。プラグインを削除すると、テーブルや行が残ることがあります。
開始する前に必要なもの
これのほとんどはダッシュボードから無料で実行できます。完全なリストは次のとおりです。
- WordPressへの管理アクセス。サイトヘルスとDBオプティマイザーはどちらもダッシュボードにあります。
- 現在のバックアップ、Duplicatorで取得したもの。データベースのみのバックアップはこの作業をカバーし、フルバックアップにかかる時間のほんの一部で完了します。
- DB Optimizer、詳細なデータベースチェックが必要な場合。Duplicator Proで無料です。
- phpMyAdminまたはホスティングデータベースアクセス。オプションであり、ステップ4の手動ルートでのみ使用します。
WordPressデータベースのヘルスチェックを実行する方法
WordPressデータベースの健全性をチェックする方法は次のとおりです。
- ステップ1：サイトヘルスでデータベースサイズのベースラインを取得します。無料、プラグイン不要、約30秒で、時間を追跡する1つの数値が得られます。
- ステップ2：DBオプティマイザーでデータベースをスコアリングします。サイズ数値を0から100のスコアに変換し、5つのバーで表示されるため、データベースのどの部分が問題であるかを確認できます。
- ステップ3：5つの指標を読み、スコアを低下させている原因を特定します。 通常の測定値と対応が必要な測定値を、指標ごとに区切るしきい値です。
- ステップ4：テーブルのオーバーヘッドと孤立した要素を監査します。 不要なスペースを占めている特定のテーブルと、削除したプラグインの残骸を見つけます。
- ステップ5：削除する前にバックアップします。 クリーンアップの失敗を軽微な問題に変えるステップです。
- ステップ6：安全なものをクリーンアップし、再スコアリングします。 プレビューと保持ウィンドウの後ろにあるジャンクを削除し、「後」の数値をベースラインと比較できるようにします。
ステップ1：サイトヘルスでデータベースサイズのベースラインを取得する
すぐにプラグインをインストールする予定でも、ここから始めてください。このステップは無料、約30秒で完了し、実行するたびに比較する数値を生成します。
ダッシュボードでツール » サイトヘルスに移動し、上部にある情報タブをクリックします。
ディレクトリとサイズセクションを展開します。データベースサイズがMB単位で表示されます。
今日の日付とともに書き留めてください。
この画面で、さらに下にあるデータベースセクションを展開します。拡張機能（MySQLまたはMariaDB）、サーバーバージョン、クライアントバージョン、および文字セットが表示されます。
サイトヘルスがデータベースについて知っていることは以上です。
ステータスタブは、リビジョン、テーブルのオーバーヘッド、プラグインテーブルの所有権、または一般的なデータベースの肥大化を評価しません。ただし、サポートされているWordPressバージョンではオートロードされたオプションを評価します。フラグが立てられた場合、オートロードされたデータのクリーンアップを促します。
ステップ2：DB Optimizerでデータベースをスコアリングする
サイズが表示されても、データベースが大きいことはわかりますが、その理由はわかりません。その理由を知るには、内部を読み取るものが必要です。それがDB Optimizerが行うことです。
DB Optimizerをインストールし、ダッシュボードから開きます。メイン画面には0から100の間のヘルススコアが表示され、その下には5つの色分けされたプログレスバーが表示されます。
- テーブルのオーバーヘッド
- 一時データ
- リビジョン
- オートロードサイズ
- ゴミ箱内のアイテム
数字だけでなく、バーも読み取ってください。リビジョンによって引き起こされた62は10分で修正できます。オートロードサイズによって引き起こされた62は、ステップ3で説明する理由により、午後の長い時間が必要です。
スコアをリフレッシュボタンは、オンデマンドで再測定します。変更後は必ず使用して、古い数値を読み取らないようにしてください。
ステップ3：5つの指標を読み、スコアを低下させている原因を特定します
データベースのヘルススコアが低い場合、その指標の正常値がわからない限り、あまり意味がありません。私が判断する基準は次のとおりです。
| 指標 | 正常 | 注意が必要 |
|---|---|---|
| オートロードサイズ | 約800KB未満 | 1MB以上 |
| wp_optionsテーブル | 通常のサイトでは3〜5MB未満 | 10MB以上 |
| 投稿リビジョン | 投稿あたり3〜5件に制限 | 無制限（デフォルト） |
| テーブルのオーバーヘッド | 最適化実行後、ほぼゼロ | チェックごとに増加 |
| ゴミ箱とスパム | スケジュールに基づいて空になりました | 蓄積された数ヶ月分 |
自動ロード、リビジョン、オーバーヘッド、およびゴミ箱は、それぞれスコア画面のバーが1つずつあります。wp_options行は、ステップ4のテーブルビューで読み取るものです。
各メトリックが何を測定しているか、および範囲外の場合に何をすべきかを説明します。
自動ロードサイズは、WordPressが使用しないリクエストを含め、すべてのページリクエスト時にメモリにロードするオプションのセットです。約800KB未満であれば問題ありません。1MB以上の場合、すべてのヒットでコストが発生し、その原因は通常、少数のプラグインがwp_optionsに大きな配列を保存していることです。
リビジョンは、スコアが悪い最も一般的な理由であり、修正が最も簡単なものです。WordPressはデフォルトで無制限に保存します。すべての投稿のすべての保存とすべての自動保存が、永久に保持されます。数百の投稿があり、複数のエディターがいるサイトでは、リビジョンは通常、実際のコンテンツ行よりも多くなります。
トランジェントは、有効期限付きのキャッシュ値です。WordPressは期限切れのものを確実にクリアしないため、蓄積されます。それらを削除しても安全であり、まだ必要なものはすべて自動的に再生成されます。
ゴミ箱アイテムには、ゴミ箱に入れられた投稿やページ、およびスパムコメントが含まれます。WordPressはデフォルトで30日後にゴミ箱を空にします。スパムコメントは、何かが削除するまで残ります。
テーブルオーバーヘッドは、削除された行が残したスペースです。1000個のリビジョンを削除しても、テーブルはそれ自体では小さくなりません。1000個の空き領域が残り、最適化を実行するとテーブルが再構築され、それらが回収されます。
ステップ4：オーバーヘッドと孤立したテーブルを監査する
スコアは、どのような種類のジャンクがあるかを示します。テーブルビューは、それがどこにあるかを示し、1つのテーブルが問題の大部分の原因であることが判明した場合に重要になります。
DB Optimizerで、テーブルビューを開きます。データベース内のすべてのテーブルとそのサイズ、およびオーバーヘッドがリストされます。1つのテーブルまたはデータベース全体を最適化および修復できます。
サイズで並べ替え、上位5つを読みます。通常のサイトでは、wp_posts、wp_postmeta、およびwp_optionsが上位に来ると予想されます。wp_optionsが上位にある場合は、ステップ3の3〜5MBのベンチマークと比較してください。
すでにデータベースアクセス権がある場合は、同じことを示す手動ルートがあります。ホスティングコントロールパネルからphpMyAdminを開き、データベースを選択し、テーブルリストをサイズ列で並べ替えます。
phpMyAdminを普段使用しない場合は、プラグインビューでカバーされているため、これをスキップしてください。
次に、もうどこにも属していないテーブルを探します。
孤立したテーブルは通常、テーブルプレフィックスとプラグイン名が付けられており、数ヶ月または数年前に削除したプラグインによって残されたものです。WordPressは削除時にプラグインファイルを削除します。プラグインの作者がそのクリーンアップルーチンを作成する必要があり、多くの人がそうしないため、プラグインテーブルを削除することはめったにありません。
特定できないテーブルは削除しないでください。テーブル名を検索し、削除したプラグインと比較して、自信を持って配置できない場合はそのままにしてください。残ったテーブルは数MBのコストがかかります。ライブテーブルを削除すると、復元が必要になります。
ステップ5：何かを削除する前にバックアップを取る
ここから先はデータベース行を削除することになるため、バックアップが必要です。
サイトのバックアップを作成してください。先週のバックアップでは、今日行っている変更はカバーされません。復元ポイントの価値は、危険な操作の直前に配置されていることです。
この作業にはデータベースのみのバックアップで十分です。Duplicator Proはファイルを完全にスキップして作成できるため、フルバックアップにかかる時間のほんの一部で完了します。
可能な限り最速のロールバックが必要な場合は、代わりに復元ポイントを使用してフルサイトバックアップを作成してください。
Duplicator ProをDB Optimizerと並べてインストールすると、何も実行される前にクリーンアップ画面でバックアップステータスの警告が表示されます。これはまさにこのためにチェックしています。
ステップ6：安全なものをクリーンアップし、再スコアリングする
バックアップが完了すれば、クリーンアップはプロセス全体の中で最もイベントの少ない部分です。
クリーンアップタブを開きます。
削除したいものを選択し、続行する前にプレビューを読んでください。アイテム数と回復できるスペースが表示されるため、確認していない数を確認することはありません。
クリーンアップの前に確認するもう1つのこと：保持設定。デフォルトでは過去7日間のものをすべて保護し、調整できます。この値はDB Optimizerの設定で見つけられます。
準備ができたら、選択したアイテムをクリーンアップをクリックして確認します。
完了したら、スコアをリフレッシュをクリックし、新しい数値を古い数値の隣に書き留めます。この比較は、ステップ1でベースラインを取得した理由です。
クリーンアップ実行の外側にある修正（リビジョンの制限、未使用タグのクリア、ピンバックの無効化）については、WordPressデータベースを最適化する方法のガイドで完全な手順を確認してください。
WordPressデータベースのヘルスチェックはどのくらいの頻度で実行すべきですか？
データベースの肥大化は元に戻ります。これは一度解決する問題ではなく、管理可能なレベルに維持する必要がある問題です。
適切なクリーンアップスケジュールは、サイトが日々どれだけ多くのことを行っているかによって異なります。
私が使用するスケジュールは次のとおりです。
- アクティブなブログ、WooCommerceストア、メンバーシップサイトの場合は月次クリーンアップ。定期的な公開、注文、ユーザーアクティビティがあるものは毎日行を生成しています。
- 年に数回編集される静的サイトの場合は四半期ごとのクリーンアップ。それ以上長くすると、比較するのに十分な読み取り値がなくなるため、成長率の信号を失います。
オフスケジュールチェックに値する瞬間がいくつかあります。これらは私が常に最初に確認するものです。
- 移行の前。肥大化したデータベースは、移行のすべての部分を遅くし、インポートがタイムアウトする可能性をさらに高めます。
- プラグインを削除した後。その時点で、孤立したテーブルが出現する可能性があります。
- 一括インポートの後。大規模なインポートは、リビジョンとpostmeta行を大量に生成します。
- ローンチまたはセールの前。トラフィックは、すでに抱えている非効率性を増幅します。
WordPressデータベースのヘルスチェックのトラブルシューティング
これらのほとんどは、より大きなサイトで発生します。私が最もよく見る問題と、それぞれに対処する方法を次に示します。
ディレクトリとサイズが「読み込み中」と表示されたまま完了しない
表示される内容: ヘルスチェックの「ディレクトリとサイズ」セクションが無限に回転し、データベースサイズが表示されません。
発生理由: WordPressはこれらの数値をディレクトリをウォークしてリアルタイムで計算します。アップロードフォルダが大きいサイトでは、リクエストが許可する時間を超える可能性があります。また、一部のホストやセキュリティプラグインがブロックするループバックリクエストにも依存します。
修正方法: まず、サイトが大きい場合は数分待ってください。それでも解決しない場合は、[ステータス]タブのループバックリクエストテストを確認してください。それが通常の原因であり、ホストに1回の返信で説明してもらうことができます。ホスティングコントロールパネルまたはphpMyAdminから直接データベースサイズを読むこともできます。
サイトヘルスとホストのレポートでデータベースサイズが一致しないのはなぜですか？
表示される内容: サイトヘルスは180MB、ホスティングパネルは400MBと表示されます。
発生理由: カウントしているものが異なります。サイトヘルスはデータとインデックスをレポートします。ホストは多くの場合、割り当てられたディスクスペースをレポートしますが、これにはデータベースがまだ使用していないスペースも含まれます。一部のホストはバイナリログや保存されたバックアップも折り込みます。
修正方法: 1つのソースを選んでそれに従ってください。絶対的な数値よりも、同じ測定値が時間の経過とともにどのように変化するかを監視することの方が重要なので、ここでは精度よりも一貫性が重要です。
身に覚えのないテーブルが見つかりました
表示される内容: データベースに、見覚えのない名前のテーブルがあります。
発生理由: プラグインは独自のテーブルを作成しますが、ほとんどのプラグインはアンインストール時にそれらを削除しません。一部のホストやセキュリティツールもテーブルを追加します。いくつかのアクティブなプラグイン（外部からは推測できない名前のもの）に属するものもあります。
修正方法: テーブルを操作する前に、正確なテーブル名を検索してください。削除したプラグインと照合してください。残骸として特定でき、ステップ5のバックアップがある場合は、削除しても問題ありません。特定できない場合は、そのままにしておいてください。テーブルが何をするかを知るために、決してテーブルを削除しないでください。
よくある質問（FAQ）
WordPressには組み込みのデータベースヘルスチェック機能がありますか？
ほとんどの人が意味するところではありません。[ツール]の下にあるサイトヘルスツールは、データベースサイズ、MySQLまたはMariaDBのバージョン、および文字セットをレポートします。リビジョン、オーバーヘッド、オートロードオプション、または孤立したテーブルは測定しません。ほとんどジャンクが集まったデータベースでも、すべてのサイトヘルスチェックに合格できます。
WordPressデータベースのサイズはどのくらい大きすぎますか？
サイトが何をするかによって異なるため、単一の数値はありません。長年の実際の注文があるWooCommerceストアは数百MBになり、良好な状態である可能性があります。100MBを超える小さなブログは、通常、多くのリビジョンや一時的なデータを抱えています。合計値だけでなく、チェック間の構成と成長率を判断してください。
データベースの健全性をチェックするためにプラグインが必要ですか？
サイズのためではありません。ツール » サイトヘルス で約30秒で無料で確認できます。中身を確認するには、リビジョン、オーバーヘッド、オートロードサイズ、ゴミ箱の数など、追加の情報が必要です。これには、DB Optimizer のようなプラグインを使用するか、phpMyAdmin を介して直接アクセスし、自分でクエリを記述する必要があります。
データベースのヘルスチェックはサイトの速度を低下させますか？
測定ではできません。テーブルサイズを読み取ったり、行数をカウントしたりするのは簡単で、日中にライブサイトで行っても誰にも気づかれません。コストがかかるのは、大きなテーブルの最適化です。なぜなら、テーブルを再構築し、実行中はロックがかかるからです。これは、最もトラフィックの少ない時間帯にスケジュールしてください。
投稿リビジョンとトランジェントを削除しても安全ですか？
はい、ただし2つの条件があります。最近のリビジョンが残るように保持期間を設定し（DB Optimizer はデフォルトで直近7日間を保護します）、最初にバックアップを取得してください。リビジョンとは、公開済みの投稿の古いコピーのことです。期限切れの一時データとは、有効期限を過ぎたキャッシュ値のことで、必要なものはすべて自動的に再生成されます。
サイトに問題があることを示す前に数値をチェックする
これで、ほとんどのサイトにはないもの、つまり日付付きのベースライン、5つの指標の評価、そしてそれらを再度確認する日付が手に入りました。WordPressデータベースのヘルスチェックは難しい作業ではありません。
最も重要なのは、次に測定する値です。忙しい四半期に15%増加したデータベースは問題ありません。ほとんど手を加えていないサイトで同じ増加が見られる場合は、知らないうちに何かが書き込まれていることを意味します。バックアップのタイムアウトのような問題が発生する前に、トラブルシューティングする価値があります。
Duplicator Pro を使用すると、バックアップをスケジュールしたり、クラウドにデータを保存したり、エラーが発生した場合にサイトをロールバックしたりできます。Pro にアップグレードすると、DB Optimizer が無料で手に入ります！
このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。
- WordPressデータベースを最適化する方法：10ステップで高速なサイトを手に入れる方法。
- WordPressデータベースクリーンアップ：ジャンクを削除するための初心者ガイド
- WordPressデータベースを高速化する方法：4つのチェックリスト
- サイト所有者が見逃しがちなWordPressデータベースの警告サイン7選
- 2026 年の最高の WordPress データベース最適化プラグイン (および 4 つの代替案)
- WordPressデータベースの更新方法（+更新が必要ですループの修正）
