WordPress 自動読み込みデータ：その概要と削除方法

サイトヘルスは、私のサイトの1つで数ヶ月間、重大な問題：「オートロードされたオプションはパフォーマンスに影響を与える可能性があります。」をフラグ付けしていました。

無視していました。サイトは問題なく動作していました。

その後、誰かが、ホームページはすぐに読み込まれるのに、ダッシュボードの読み込みに10秒近くかかるのはなぜだと尋ねました。そこで、ついにオートロードサイズを確認したところ、データベースに数メガバイトのオプションがあり、そのほとんどは数年前にアンインストールしたプラグインによって書き込まれたものでした。

残念なことに、このトピックに関するほとんどのアドバイスは古くなっています。WordPress 6.6はオートロードの仕組みを変更し、ほとんどのガイドで現在公開されているクエリは間違った数を返します。

標準的なクリーンアップのアドバイスの多くは、WordPressコアに隠された理由により、オートロードサイズを削減しません。

この記事では、WordPressのオートロードデータとは何か、最新のインストールでそれを正しく測定する方法、削除しても安全なもの、そしてサイトを壊さずにクリーンアップする方法を説明します。

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

• オートロードデータは、管理画面、REST呼び出し、cronジョブを含む、WordPressに到達するすべてのリクエストで読み込まれるため、ページキャッシュでは決して隠すことができません。
• WordPressは、800 KBを超えるオートロードされたオプションに対して重大なサイトヘルス問題をフラグ付けします。これは、公式の制限に最も近いものです。
• ほとんどのガイドのSQLクエリは現在、過小評価しています。WordPress 6.6は、古いはい/いいえのオートロード値を5つの可能な値に置き換えました。そのため、autoload='yes'でフィルタリングすると、新しい行が見逃されます。
• 期限切れの一時データをクリアしても、オートロードサイズはほとんど変わりません。有効期限付きで作成された一時データは、そもそもオートロードされないため、データベースクリーンアッププラグインはここでは何も機能しないように見えます。
• 実際の肥大化は通常、数年前に削除したプラグインによって残された、孤立したプラグインオプションです。それらを自動的にクリーンアップするものは何もありません。
• DuplicatorのDB Optimizerは、データベースの健全性スコアの一部としてオートロードサイズを測定します。これにより、時間の経過とともに数値を追跡する最も簡単な方法になります。オートロードされたオプションのクリアは、依然として手作業です。
• オートロードをオフにすることは、削除することよりも安全です。プラグインが必要な場合に備えてデータはデータベースに残され、変更は元に戻すことができます。
• 現在のバックアップなしでwp_optionsを編集しないでください。サイト全体をオフラインにできる唯一のテーブルを操作しています。
• クリーンアップ後数日でオートロードサイズが元に戻る場合は、プラグインが実行ごとにそれを書き込んでいることを意味し、どれだけクリーンアップしても効果はありません。

目次

WordPressにおけるオートロードデータとは？

すべてのWordPressサイトは、wp_optionsというデータベーステーブルに設定を保存します。サイトのURLはそこにあります。アクティブなプラグインのリスト、テーマの設定、インストールしたほぼすべてのプラグインの設定も同様です。

そのテーブルの各行には、autoload列があります。その列は1つの質問に答えます。WordPressはこの行をすべてのページで読み込むべきか、それとも誰かがそれを要求したときにのみ読み込むべきか？

答えが「はい」の場合、そのオプションは自動ロードされます。それが用語の意味するところです。現在のページで必要かどうかに関わらず、自動的に読み込まれます。

WordPressはこれを正当な理由で行っています。プラグインが設定を要求するたびに個別のデータベースクエリを実行するのではなく、リクエストの開始時に自動ロードされるすべてのオプションを1つのクエリで取得し、メモリに保持します。1つのクエリは、数百の小さなクエリよりも優れています。

自動ロードされるオプションとして通常保存されるものは次のとおりです。

• コア設定サイトがsiteurl、home、active_plugins、template、stylesheetなしでは実行できないもの
• プラグイン設定、多くの場合、プラグインごとに1つの大きなシリアライズされた配列として保存されます
• プレミアムプラグインやテーマからのライセンスキーとアクティベーションデータ
• 適切なトランジェントではなく通常のオプションとしてプラグインが保存したAPIレスポンスのキャッシュ
• 削除したプラグインの残り物、何も自分でクリーンアップしないもの
• 有効期限なしで作成されたトランジェント、デフォルトで自動ロードされるもの

設計は問題ありません。問題を引き起こすのは蓄積です。

オートロードデータがサイトを遅くする理由

WordPressに到達するすべてのリクエストは、自動ロードのサイズを負担します。これは、訪問者からのページビューだけでなく、管理画面、REST API呼び出し、WP-Cronジョブ、AJAXリクエスト、およびプラグインが起動するすべてのバックグラウンドタスクにも影響します。

コストはクエリだけではありません。オプション値はシリアライズされて保存されるため、PHPはロードごとにそれらすべてをメモリにアンシリアライズする必要があります。3MBの自動ロードテーブルは、コンテンツの1単語もレンダリングする前に、サイトが3MBのPHP配列を再構築することを意味します。

それはメモリとCPUであり、すべてのリクエストで、永遠に。

ページキャッシュはここでは役に立ちません。キャッシュは訪問者に完成したHTMLページを提供するため、それらのリクエストはWordPressを完全にスキップします。あなた自身の要求はそうではありません。

肥大化した自動ロードテーブルが最初に現れるのは次のとおりです。

• wp-adminが遅く感じられる一方、フロントエンドは高速のままです。管理画面はキャッシュされないため
• ブロックエディターの保存または読み込み時に遅延が発生します。すべてのエディターリクエストが完全なWordPressロードを経由するため
• WooCommerceのカートとチェックアウトが遅くなります。これらのページは設計上キャッシュから除外されているため
• ログインユーザーは他のユーザーよりもサイトが遅くなります。これにより、問題の再現が困難になります
• Cronジョブが積み重なります。それぞれが同じオーバーヘッドを負担するため

ホストから「データベースは問題ないがダッシュボードが遅い」と言われたことがある場合、通常はこれが原因です。自動ロードサイズは、ほとんどのホストがチェックするメトリクスには表示されません。

しかし、スコープについては正直に言いたいと思います。オートロードの肥大化は、サイトの動作を遅くする唯一の原因であることはめったになく、それを解消しても、ホストが遅く画像が最適化されていないサイトを救うことはできません。

それは、ほとんど誰もチェックしない部分であり、サイトを実行し続ける限り、毎月静かに増加していきます。

WordPressのオートロードデータは多すぎるとどうなりますか？

この質問を検索すると、5つの異なる答えが得られます。300KBだと言うガイドもあれば、1MBだと言うガイドもあります。

WordPress 6.6 は、すべての人のために一線を引きました。サイトヘルスは、オートロードされるオプションの合計が800KBを超えると、現在、重大な問題を表示します。

実務における範囲の読み方は次のとおりです。

• 800KB未満：健全。サイトヘルスは静かで、追跡すべきものはありません。
• 800KBから1MB：確認する価値あり。コアのしきい値を超えており、通常は1つまたは2つのプラグインが原因です。
• 1MBから3MB：実際の問題。特に共有ホスティングでは、管理画面の動作が著しく遅くなることが予想されます。
• 3MB超：何かが定期的にジャンクを書き込んでいる可能性があり、見つけ出すまでクリーンアップしても効果は持続しません。

site_status_autoloaded_options_size_limitフィルターを使用してしきい値を引き上げることができますが、それは警告を隠すだけです。クエリは同じサイズで実行され続けます。

サイズだけではすべてがわかるわけではありません。百個の小さな孤立した行は、2022年に使用をやめたスライダープラグインからの2MBのシリアライズされた配列1つよりも、あなたの注意を引く価値は低いです。

数ではなく、最大の違反者を追跡してください。

知っておくと良いもう一つの良い習慣があります。WordPress 6.6以降、150KBを超える新しいオプションは、デフォルトでオートロードされないように設定されます。

コアがその決定を下したのは、大きすぎるオートロードオプションが非常に一般的なパフォーマンスの問題だったためです。これはwp_max_autoloaded_option_sizeでフィルターできますが、引き上げるのは悪い考えです。

その保護は、今後のみ適用されます。データベースにすでに存在する以前のものは、これまでどおりオートロードされ続けます。

ほとんどのオートロードガイドが現在間違った数値を提示している理由

WordPressの歴史のほとんどにおいて、オートロード列にはyesまたはnoのいずれかの値が含まれていました。シンプルです。オートロードデータに関するすべてのチュートリアルは、その仮定に基づいていました。

WordPress 6.6 は、5つの可能な値に置き換えました。

• on：明示的にオートロードに設定されており、常にそうなります。
• off：明示的にオートロードしないように設定されており、決してそうしません。
• auto：明示的な設定がなかったため、WordPressが決定します（そして現在オートロードしています）。
• auto-on：WordPressが動的にオートロードすべきだと判断しました。
• auto-off：WordPressが動的にオートロードすべきではないと判断しました。通常、値が150KBを超えるためです。

既存の行は移行されませんでした。変更前に作成されたオプションは、元のyesおよびno値を保持しており、コアはそれらをonおよびoffと同等に扱います。

したがって、6.6のアップグレードをまたいで実行されているサイトは、現在、同じ列に古い値と新しい値の両方が混在しています。

多くの人がautoload='yes'でフィルタリングされたクエリを実行するように勧めるでしょう。最新のサイトでは、そのクエリは6.6以降に書かれたすべてのオプションと、自動または自動オンとマークされたコアのものをすべて静かにスキップします。

数値は得られます。それはあなたの数値ではなく、常に低すぎます。

修正するには、WordPressがオートロードとして扱うすべての値に対してチェックする必要があります。コアはwp_autoload_values_to_autoload()を通じてそのリストを正確に公開しており、デフォルトでyes、on、auto-on、autoを返します。

代わりに実行すべきSQLクエリは何ですか？

phpMyAdminまたはホストのデータベースツールにアクセスできる場合は、これらの2つのクエリで必要なほとんどすべてを知ることができます。SQLタブでサイトのデータベースに対して実行してください。

wp_optionsに対して何かを実行する前に、バックアップを作成してください。これらの2つのクエリはデータを読み取るだけで何も変更しませんが、次のセクションでは行を編集するので、安全策を講じるに越したことはありません。

合計オートロードサイズから始めましょう：

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

これは、関連するオプションの数とともに、合計サイズをキロバイト単位で返します。前のセクションの800 KBのしきい値と比較してください。

次に、何が原因かを突き止めましょう：

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

これは、名前、個々のサイズ、現在のオートロード値とともに、20個の最大のオートロードオプションを返します。ほとんどのサイトでは、上位3〜4行が問題の大部分を占めています。

これらをコピーする前に、2つの点に注意してください：

• テーブルプレフィックスがwp_ではない可能性があります。多くのインストールでは、セキュリティ上の理由からカスタムプレフィックスを使用しています。$table_prefixの値を確認するためにwp-config.phpを確認し、クエリに置き換えてください。
• マルチサイトは動作が異なります。各サブサイトには独自のオプションテーブル（wp_2_options、wp_3_optionsなど）があり、さらにネットワーク全体のwp_sitemetaテーブルがあります。これらは個別に確認する必要があります。

コマンドラインを使用したい場合は、WP-CLIがそれぞれ1行で両方のジョブを処理します。これはバイト単位で合計を返します：

wp option list --autoload=on --format=total_bytes

そしてこれは、保存されたサイズとともにオートロードされたオプションを一覧表示します：

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

すべての人がデータベースコンソールに触れたいわけではありませんし、触れる必要もありません。次のセクションでは、WordPressダッシュボード内に留まる2つの方法を説明します。

WordPressのオートロードサイズを確認する方法

測定していないものを修正することはできません。また、行った変更ごとに再度測定したくなります。

データベースにどれだけ近づきたいかによって、数値を取得する方法は3つあります。

オプション1：サイトヘルス（最も速いルート）

WordPressはすでにこれをチェックしています。ツール » サイトヘルスに移動し、ステータスタブを開き、リストでオートロードされたオプションがパフォーマンスに影響を与える可能性がありますを探してください。

展開すると、合計サイズが表示されます。

ただし、このチェックは800 KBを超えた場合にのみ表示されます。沈黙はゼロであることを意味するのではなく、線の下にあることを意味します。また、履歴がなく、表示されたものに基づいてアクションを実行する方法もない、単一のスナップショットを提供します。

オプション2：DBオプティマイザーのヘルススコア（追跡が最も簡単）

オートロードサイズを一度チェックするのではなく、時間の経過とともに追跡したい場合は、DBオプティマイザーがダッシュボードに表示します。

DB Optimizerを開くと、0から100までのデータベースの健全性スコアが得られます。5つのカラーコード付きバーがスコアを内訳します：テーブルオーバーヘッド、一時データ、リビジョン、オートロードサイズ、ゴミ箱アイテム。

これが何をするもので、何をしないものなのかを明確にさせてください。DB Optimizerはオートロードサイズを測定し、それを報告します。オートロードされたオプションはクリアしません。

オートロードされたデータを削除するのは、まだ手作業です。以下でその手順を説明します。

クリアするのは、投稿リビジョン、自動下書き、ゴミ箱コンテンツ、スパムコメント、期限切れの一時データ、ピンバック、トラックバック、oEmbedキャッシュです。これらは本当にクリアする価値があります。これらはオートロードとは別の問題です。

手動でのクリーンアップを開始する前に、簡単なデータベースクリーンを実行しても損はありません。クリーンアップタブを開き、利用可能なすべての最適化を実行してください。

次に、テーブルタブに移動します。オーバーヘッドのあるすべてのテーブルを最適化してください。

ダッシュボードでスコアの更新をクリックし、オートロードサイズに何が起こるか見てみましょう。

• スコアが著しく増加します：期限切れのない一時データが問題の一部であり、それをいくつかクリアしました。
• スコアはほとんど動きません：あなたの肥大化は孤立したプラグインオプションであり、どのクリーンアップツールもそれに触れることはありません。手動の方法に直接進んでください。
• スコアが増加し、数日以内に元に戻ります：アクティブなプラグインが実行ごとにオートロードされたオプションを書き換えています。

この最後のケースは、早期に検出する価値があります。毎月同じ行をクリーンアップして、なぜ何も定着しないのか疑問に思うことから解放されます。

DB Optimizerは、最近のバックアップがない場合にも警告し、作成するためのリンクを直接提供します。これはDuplicator ProおよびEliteプランに無料で含まれていますので、サイトを安全にスムーズに実行し続けることができます。

オプション3：自分でクエリを実行する（最も正確）

前のセクションのSQLおよびWP-CLIコマンドは、正確な数と完全なランキングリストを提供し、しきい値によって何も隠されることはありません。

これは、何かを変更しようとするときに使用するルートです。なぜなら、それは各行の現在のオートロード値をすべて表示する唯一の方法だからです。編集を開始する前にそれが必要です。

データベースクリーンアップでオートロードサイズが修正されなかったのはなぜですか？

このトピックに関するほぼすべての記事で見つかるアドバイスは次のとおりです。一時データをクリアすれば、オートロードサイズが減少します。

それはほとんど間違っており、WordPressコアでそれを証明できます。

一時データを作成するときにset_transient()が何をするか見てみましょう。有効期限を指定すると、WordPressはその一時データをオートロードをfalseに設定して保存します。オートロードされるのは、有効期限なしで作成された一時データのみであり、それらは少数派です。

期限切れの一時データは、定義上、期限があった一時データです。これは、それらがオートロードされなかったことを意味します。5万個削除しても、wp_optionsテーブルを100メガバイト縮小しても、オートロードの数はほとんど変わりません。

どちらのクリーンアップも行う価値があります。巨大なwp_optionsテーブルはクエリを遅くし、バックアップを肥大化させ、マイグレーションをタイムアウトさせます。それは単に異なる問題であり、異なる修正が必要であり、この2つを混同することが、多くの人がクリーンアッププラグインが壊れていると思う理由です。

では、トランジェントがなくなると何が残るのでしょうか？私の経験では、ほぼ常に次のいずれかです。

• アンインストールしたプラグインのシリアライズされた設定配列。ほとんどのプラグインは削除時に自分たちの後始末をせず、それらの設定は永遠にオートロードされ続けます。
• プレミアムプラグインのライセンスとアクティベーションデータ。数年前にライセンスが失効したプラグインも含まれます。
• 通常のトランジェントではなく、プレーンなオプションとして保存されたAPIレスポンスのキャッシュ。通常はソーシャルフィード、分析、またはSEOプラグインによるものです。
• 無制限に増加するログスタイルのオプション。プラグインが独自のテーブルを使用する代わりに、すべてのイベントで単一のオプション行に追加していく場合です。
• 期限切れのないトランジェント。これはここでの真の例外であり、トランジェントクリーンアップが役立つ唯一の種類です。

これらのどれもワンクリックツールでは削除できません。それが正直な答えであり、次のセクションが手作業である理由です。

WordPressのオートロードデータをクリーンアップするにはどうすればよいですか？

これを1回のクリックで修正するプラグインはありません。オートロードされるオプションをクリアするには、特定の行を特定し、それぞれに対して何を行うかを決定する必要があります。

それは聞こえるほど悪くはありません。ほとんどのサイトでは、3つか4つの行が問題の大部分を占めているため、数百ではなく3つか4つの決定を行うことになります。

ここでは3つの方法を紹介します。最も安全なものから最も手間のかかるものの順です。

• 重いオプションのオートロードをオフにする：何も削除せずに単一の列値を切り替えます。完全に元に戻すことができます。
• 削除されたプラグインの孤立したオプションを削除する：完全に削除されたプラグインによって残された行を永続的にクリアします。
• 書き込みを続けるプラグインを置き換える：実行ごとにブロートを再生成し続けるものに対して有効な唯一の修正です。

いずれかを始める前に、完全なバックアップを取ってください。Duplicator Proは数分でデータベースとファイルの完全なコピーを作成し、そのワンクリック復元は、悪いUPDATEステートメントが週末ではなく10分で済むことを意味します。

方法1：重いオプションのオートロードをオフにする

ここから始めてください。何も削除されないからです。単一の列値を変更しており、元に戻すことができます。

クエリから上位の違反者リストを取得し、それに取り組みます。各大きなオプションについて、サイトがページロードごとにそのデータが必要かどうかという問題があります。

オートロードを無効にする前に、プラグインがオプションをどのように、どこで読み取るかを確認してください。一部の設定配列は、フロントエンドリクエストで正当に必要とされます。他のものは管理者専用またはめったにアクセスされず、オンデマンドでロードする方が良いです。

オプションのオートロードを停止するには、そのオートロード値を更新します。

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

WordPress 6.6以降ではoffを使用してください。WordPressはレガシーなno値も非オートロードとして認識するため、古いインストールとの互換性が保たれます。

WP-CLIは1つのコマンドでこれを処理し、on、off、yes、またはnoを受け入れます。

wp option set-autoload your_option_name_here off

データはそのまま残ります。WordPressは、リクエストごとに読み込むのを停止し、get_option()が呼び出されたときにオンデマンドで取得するだけになります。

変更を加えるたびに、2つのことを行います。サイズクエリを再実行して数値が減少したことを確認し、フロントエンドとwp-adminの両方を読み込んで、何も壊れていないことを確認します。

20個の変更をバッチ処理してからテストしないでください。何か問題が発生した場合、どの行が原因だったかを知りたいはずです。

注意すべき点：プラグインの更新後にオプションが自動ロードに戻った場合、そのプラグインはアクティブ化またはアップグレード時に値を上書きしています。あなたの変更は失敗したのではなく、上書きされました。

それはプラグインの開発者にサポートチケットを出す価値があり、あなたが方法3に向かっていることを強く示唆しています。

方法2：削除されたプラグインから孤立したオプションを削除する

削除は永続的なので、この方法は前の方法よりも注意が必要です。

上位の違反者リストを調べ、各オプション名をそれを作成したプラグインに一致させます。ほとんどは認識可能なプレフィックスを使用していますが、すべてが明白なわけではありません。

触る前にオプション名を検索してください。見捨てられたように見える名前でも、まだ実行中の何かに属している場合があります。

次に、プラグインが本当に削除されたことを確認します。

無効化されただけでは削除されたことになりません。無効化されたプラグインは、ディスク上にファイルを持っており、再アクティブ化すると設定をすぐに復元します。そのため、無効化中にオプションを削除しても、設定が失われるだけです。

オプションを削除する前に、削除しようとしている正確な行を対象としていることを確認してください。この読み取り専用クエリは、何も変更せずに、オプションのID、名前、現在の自動ロードステータス、および保存されているサイズを表示します。

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

確信したら、行を削除します。

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

このテーブルで、LIKEワイルドカードを使用してDELETEを実行しないでください。必ず、一致するすべての行を最初に読んでください。特定のパターンに見えるものでも、予想以上に多くに一致する可能性があります。wp_optionsは、間違いが1つの機能を壊すのではなく、サイト全体をダウンさせる唯一のテーブルです。

行をまったく特定できない場合は、削除しないでください。方法1を使用して自動ロードをオフに切り替え、そのままにしておきます。

パフォーマンスのメリットを最大限に享受でき、データは保持され、何かが必要になった場合に数秒で元に戻すことができます。

ここでバックアップが形式的なものではなくなります。WordPressデータベースの最も重要なテーブルから行を削除しており、Duplicator Proの災害復旧URLは、悪いクエリがwp-adminへのアクセスをブロックした場合でもサイトを復元します。

方法3：書き込みを続けるプラグインを置き換える

クリーンアップ後数日以内に自動ロードサイズが1MBを超えて再び増加する場合は、クリーンアップを中止してください。何かのアクティブな書き込みが毎回発生しており、永遠にこの作業を続けることになります。

私がよく見つけるものに基づいた、一般的な原因です。

• スライダーおよびページビルダープラグイン：巨大なシリアライズされた設定配列を保存するもの
• 分析および統計プラグイン：独自のテーブルではなくオプション行にログを記録するもの
• セキュリティプラグイン：イベントログをオプションとして保持するもの
• 放棄されたリダイレクトマネージャー：すべてのリダイレクトルールが1つの増え続けるオプションに格納されるもの
• ソーシャルフィードプラグイン：API応答を通常の自動ロードオプションとしてキャッシュするもの

犯人を見つけるのは、言うほど簡単ではありません。上位の違反者を確認し、数日待ってからクエリを再実行してください。増えたものが答えです。

ライブサイトでプラグインをスワップするのは危険であり、本番環境で最初に決して行わないプロセスの一部です。

Duplicator Proを使用すると、追加のホスティングアカウントや手動のファイル転送なしで、数回のクリックで任意のフルサイトバックアップをステージングサイトに変換できます。

そこで置換をテストし、サイトがまだ機能しており、オートロードサイズがフラットであることを確認してから、本番環境で変更を行ってください。

WordPressのオートロードデータが戻ってくるのを防ぐにはどうすればよいですか？

WordPressのオートロードデータは通常のサイトメンテナンスの副産物として増加するため、クリーンアップは一度限りの仕事ではありません。試したすべてのプラグインが何かを残します。

再び手に負えなくなるのを防ぐためのいくつかの習慣:

• 毎月、またはプラグインの変更バッチ後にスコアを確認してください。 DB Optimizerのダッシュボードはこれを10秒のジョブにしますが、プラグインを追加したくない場合は、サイトヘルスでも問題ありません。
• プラグインを非アクティブ化するのではなく、適切に削除してください。非アクティブ化すると、すべてのオプションがそのまま残ります。削除することで、少なくともよく構築されたプラグインはクリーンアップの機会を得ますが、それでも多くのプラグインはそうしません。
• アンインストールする前にオプションを確認してください。プラグインがデータを残すことがわかっている場合は、まだインストールされていて特定しやすい間に、そのオプション名をメモしてください。
• プラグインの数を減らしてください。これはこのリストの中で最も満足度の低いアドバイスですが、最も効果的です。試さないすべてのプラグインは、クリーンアップする必要のないオートロードデータです。
• 定期的に最新のバックアップを実行してください。これにより、データベースのクリーンアップは神経質な決定ではなく、リスクの低い決定になります。
• サイトが遅くなるのを待つのではなく、サイトヘルスに注意してください。遅延に気づく頃には、通常は2MBを超えています。

よくある質問（FAQ）

WordPressのオートロードデータは、一度限りの修正ではなく、メンテナンスの習慣です

オートロードの肥大化は、サイトがこれまで試したすべてのプラグインの累積コストです。これは問題の捉え方を変えるので、じっくり考える価値があります。

これはバグでも、あなたが何か間違ったことをした兆候でもありません。数年間WordPressサイトを運営してきた通常の残骸であり、WordPressにはそれをクリーンアップしてくれるものはありません。

関わる作業については、率直に申し上げたいと思います。wp_optionsを手動で編集することは現実的なリスクを伴い、利用可能なツールは問題を修正するよりも測定する方が容易であり、プラグインをインストールし続ける（そしてあなたはそうするでしょう）なら、6か月後にここに戻ってくるでしょう。

リマインダーを設定し、四半期ごとに数を確認し、他のメンテナンスタスクのように扱ってください。

まだ言及していない、もう一つやる価値のあることがあります。移行の直前にオートロードサイズを確認してください。これは、バックアップアーカイブを縮小し、反対側でのインポート時間を短縮するための最も安価な方法です。

肥大化したwp_optionsテーブルは、新しいホストでデータベースのインポートが停止またはタイムアウトする最も一般的な理由の1つであり、移行の失敗をデバッグするのは本当にイライラします。エクスポートする前に10分間のクリーンアップを行えば、それを完全に回避できます。

wp_optionsに触れる前に、サイトが保護されていることを確認してください

オートロードデータのクリーニングは、サイト全体をオフラインにできる可能性のある1つのテーブルに対してUPDATEおよびDELETEステートメントを実行することを意味します。クエリでワイルドカードを1つでも間違えると、wp-adminにアクセスできなくなり、白い画面が表示されます。

Duplicator Proは、そのような間違いを災害ではなく回復可能なものにします。開始する前に完全なバックアップを取り、何か問題が発生した場合はワンクリックで数分で復元できます。

その災害復旧URLは、WordPressが完全にロックアウトされている場合でもサイトを復旧させます。これは、悪いデータベースクエリが作成するまさにそのシナリオです。今日試してみてください！

この投稿を読んで、データベースに他に何が残っているかについて考えさせられたなら、これらのガイドを読む価値があります。

• WordPressで全てのトランジェントを削除する方法（4つの方法）
• WordPressデータベースの最適化方法：10ステップで高速サイトを実現
• WordPressデータベースクリーンアップ：ジャンクを削除するための初心者ガイド
• サイト所有者が見逃しがちなWordPressデータベースの警告サイン7選
• WordPressデータベースを高速化する方法：4つのチェックリスト
• WordPressデータベースメンテナンス：毎週、毎月、四半期ごとに行うべきこと