...
ウェブホスティングのロゴ

WordPressのオートロードデータを分析重要なエントリーを最適化

私は分析する ワードプレスのオートロード-dataで、wp_optionsテーブルのオーバーサイズのエントリを特定し、重要な候補を削除します。これにより、自動的にロードされるオプションの全体的なサイズが縮小され、TTFBが削減され、RAMが解放され、バックエンドとフロントエンドが確実に高速化されます。.

中心点

以下のポイントは、詳細を説明する前にコンパクトに概要を説明するものである。.

  • オートロードサイズ サイズを小さくする（理想：1～2MB未満）
  • トップ汚染者 見つける（トランジェント、大きなアレイ、プラグインの残骸）
  • SQLチェック サイズ、数、トップエントリーについて
  • 的を絞って autoload=’no'に設定するか、削除する。
  • モニタリング そして毎月のメンテナンスを確立する。

このリストでは、意図的に無駄を省き、焦点を絞ることで、最大のレバーをすぐに認識できるようにしている。各対策は、顕著なロード時間に直接的な影響を与えます。ステップは安全にテストでき、必要であれば元に戻すこともできる。私は分析、クリーンアップ、モニタリングを明確なプロセスで組み合わせている。これが、持続可能な速さを実現する方法です。 ページビュー.

オートロードデータがパフォーマンスを低下させる理由

リクエストごとに、WordPress はすべてのオプションを autoload=これらの値の合計が数メガバイトになると、遅延、TTFB、RAMの要件が大幅に増加します。これらの値の合計が数メガバイトになると、レイテンシ、TTFB、RAMの要件が大幅に増加します。特に、大きな直列化配列、古いトランジェント、アンインストールプラグインの残骸は、オートロード量を増大させます。これはPHPとMySQLにとって不必要な作業につながり、特にバックエンドが著しく遅くなります。そこで私は、ページリクエストごとにメモリに入るものすべてに優先順位をつけ バラスト.

実際の状態を測定します：サイズと数を素早くチェック

何かを変更する前に、自動的にロードされたオプションの現在のデータ状況を wp_options-テーブルに追加する。これを行うには、単純なSQLクエリを使って合計サイズを求め、それにエントリー数を加える。その結果をMBに換算し、目標を設定し、次のステップを計画する。合計が1-2MBを超えるか、数が500を大幅に超える場合、私は集中的な分析を開始する。この最初の調査によって、すでに明確になり 優先順位 固定。.

-- オートロードデータの合計サイズ（バイト
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes'；

-- オートロードエントリーの数
SELECT COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes'；;

重要なエントリーを特定し、優先順位をつける

私はまず最大の塊を特定する。 負荷. .トランジェント（_transient_*、_site_transient_*）やロール定義（_user_roles_）、あるいは常時使用されるわけではないプラグインのログや統計をよく見かけます。WooCommerceやSEOプラグインも、広大な配列を保存したがります。私は、1つのオプションにつき100～200KBを超えるものをよく見て、50KBを超えるトランジェントを一貫して削除している。もっと詳しく知りたい場合は、私の詳細な データベース・チューニング・ブースト を、理にかなった方法で一連の小節をこなすための追加ガイドとして使用する。.

-- トップ・オリジネーターをMBに表示する
SELECT option_name, autoload、
       ROUND(LENGTH(option_value) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_mb DESC
LIMIT 20；;

詳細分析：パターン、接頭辞、直列化

的を射た方法で片付けるために、私はオートロードの量を以下のように切り分けた。 接頭辞 とデータ・フォームを作成した。これによって、どのプラグインや機能領域が特に強く貢献しているのか、また大きな直列化された配列が支配的なのかをすぐに確認することができる。直列化されたデータは、次のような開始パターンによって見分けることができる。 a:... (配列）または O:... (オブジェクト）。大きな入れ子配列は、典型的な autoload=no あるいは、より小さなユニットに分割される。.

-- 単純な）接頭辞による分布
SELECT
  SUBSTRING_INDEX(option_name, '_', 1) AS prefix、
  COUNT(*) AS cnt、
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'
GROUP BY prefix
ORDER BY size_mb DESC
LIMIT 20；

-- 大きな直列化された配列を識別する
SELECT オプション名、
       LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
  AND option_value REGEXP '^a:[0-9]+:'
ORDER BY len DESC
LIMIT 20；

-- JSONタイプのコンテンツをチェックする（大まかなフィルタのみ）
SELECT option_name、
       LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
  AND option_value LIKE '{%'
ORDER BY len DESC
LIMIT 20；;

あるプラグインに対して非常に大きなオプションがいくつか見つかった場合 ストレージ戦略 問題（例えば、キャッシュやログを1つのオプションにする）を解決することができる。これはしばしば軽減できる：データを分割する、不要な部分を削除する、プラグインの設定でロギングを減らす。.

目標クリーンアップ：トランジェント、autoload=no、orphanedオプション

期限切れのトランジデントについては、不要なスペースを占有することが多いので、期限切れのエントリーを削除している。 メモリ. .めったに使わない大きなオプションをautoload=’no'に設定し、その直後にページの機能をテストする。リモートプラグインの痕跡を見つけたら、wp_optionsテーブルからそれらの接頭辞を制御された方法でクリーンアップします。すべてのステップは、最新のバックアップと明確なフォールバック・レベルを使用して実行されるので、常に安全です。こうすることで、オートロードの合計は素早く縮小し TTFB の利益を得ることができます。

-- 期限切れのトランジェントを削除する (まずバックアップを!)
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
   OR option_name LIKE '_site_transient_%'；

-- オートロードから単一の大きなオプションを削除する
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'EXAMPLE_OPTION'；

-- 認識可能な接頭辞を持つ、孤児となったプラグインオプションを削除する
DELETE FROM wp_options
WHERE option_name LIKE 'altplugin_%'；;

盲目的な削除ではなく、安全な削除

私が 期限切れ トランジェントが発生した場合は、タイムアウトオプションを考慮した特定のクエリーを使用する。これはより優しく、キャッシュ時の副作用を減らすことができます。別の方法として、WP-CLIは1つのコマンドで仕事をします。.

-- 期限切れ(サイト)のトランジェントだけを削除する(より安全)
DELETE a, b
FROM wp_options a
JOIN wp_options b
  ON b.option_name = REPLACE(a.option_name, '_transient_', '_transient_timeout_')
WHERE a.option_name LIKE '_transient_%'
  AND a.option_name NOT LIKE '_transient_timeout_%'
  AND b.option_value < UNIX_TIMESTAMP()；

a, bを削除する
FROM wp_options a
JOIN wp_options b
  ON b.option_name = REPLACE(a.option_name, '_site_transient_', '_site_transient_timeout_')
WHERE a.option_name LIKE '_site_transient_%'
  AND a.option_name NOT LIKE '_site_transient_timeout_%'
  AND b.option_value < UNIX_TIMESTAMP()；

-- WP-CLI (推奨): 期限切れのトランジェントを削除する
#単一サイト
wp transient delete --expired
# マルチサイト
wp transient delete --expired --network

の場合 ロールバック 私は事前に、名前の収集、内容のエクスポート、変更のログなど、最大のオプションを個別に保存しています。これにより、問題が発生した場合、個々の値を数秒で復元することができるんだ。.

# オートロード名トップ50のエクスポート
wp db クエリ "
SELECT オプション名
FROM wp_options
WHERE autoload='yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 50
" -カラム名をスキップ > big_options.txt

# 内容を保存する（簡単なテキスト形式）
while read -r NAME; do
  printf '=== %s ===n' "$NAME" >> backup_options.txt
  wpオプション取得 "$NAME" >> backup_options.txt
完了 < big_options.txt

テーブルのメンテナンスとメモリの衛生管理

クリーンアップの後、削除されたデータ・ブロックがフリーになるようにテーブルを最適化する。 データベース が再び効率的に動作するようにする。このステップは断片化を減らし、MySQLの今後のクエリに役立ちます。その後、オートロードのサイズを再度チェックし、成功が測定可能な状態に保たれるようにする。オプションで、RedisやMemcachedのようなオブジェクトキャッシュを追加すると、残りのオプションのロードが加速される。キャッシュがなくても、リクエストごとに RAM ハイキング.

-- メモリの解放と統計情報の更新
OPTIMIZE TABLE wp_options；;

ツールとWP-CLIで自動化する

定期的なインストールにかかる時間を節約するために、私は選択した。 ツール とスクリプトを使用しています。WP-CLIは、例えば、いくつかの大きなオプションをautoload=’no'に設定し、それらを直接チェックするなど、大量のアップデートを実行することができます。定期的にトランジェントをクリーンアップし、テーブルを最適化するために、明確なロギングで無駄のないプラグインを使用しています。それぞれの自動化の前に、私は初期値を文書化し、利点とリスクを比較検討できるようにしています。wp_optionsをより高速に使いたい場合は、以下のサイトを参照してください。 wp_optionsのパフォーマンス・チューニング 分析とスクリプティングの賢明な組み合わせのための追加アイデア。.

# 例：大きなオプション名のリストを見て、オートロードを無効にする。
while read -r NAME; do
  wp option update "$NAME" "$(wp option get "$NAME")"--autoload=no
完了 < names.txt

モニタリングと予防：TTFBとRAMの概要

クリーンアップした後、オートロードの合計が再び現れないように簡単なルーチンを設定した。 上昇する. .毎月の合計サイズのチェックと、上位10個のオプションのチェックで十分です。値が大幅に増加した場合は、最近インストールしたプラグインとその設定をチェックします。同時に、TTFB、PHPメモリ使用量、データベース時間を監視し、改善を可視化します。これらの対策は、良いホスティングほど強い効果を発揮します。 勝利 さらに強化された。.

閾値と対策が一目でわかる

次のステップを分類するために、私は明確な方法を用いている。 バウンダリー, 迅速な意思決定を可能にする。私は、重要でないエントリーで時間を無駄にすることなく、まず最大の原因を優先する。この表は、典型的な閾値とそれに対する私の標準的な対応を示している。これは分析に取って代わるものではないが、最初の数ラウンドは自信を与えてくれる。より深く分析するのであれば、より細かい調整を行い、閾値を最適化することができる。 コントロール 凝縮する。.

タイプ しきい値 アクション
オートロード・サイズ < 1-2 MB メンテナンス、毎月の点検
オートロード・サイズ 2-5 MB 最大10のオプションをチェックし、トランジェントをクリーンアップ
オートロード・サイズ > 5 MB めったに使われないオプションはオートロード=なし。
シングル・オプション > 100-200 KB 原因をチェックし、必要であればautoload=noに設定する。
トランジェント > 50 KB 削除し、後でクリーンキャッシュで再作成する。

リスクを回避し、安全にテストする

重要なオプションの変更は、新鮮な状態でなければ決して行わない。 バックアップ そして、戻る道も考えずに。削除する前に、siteurlやhomeのような中心的なコアオプションが関係しているかどうかをチェックする。すべての変更後、私はフロントエンドとバックエンドを新鮮なセッションでロードし、ページの影響を早い段階で認識します。問題が発生した場合は、バックアップから以前の状態を復元し、スモールステップで進めます。こうすることで、最適化はコントロール可能なまま維持されます。 安定性 インストールの.

実例：低速から高速へ

20MB以上のオートロードデータがあるインストレーションでは、まず大きなトランジェントを削除し、次に3つのかさばるオプションを設定した。 autoload=no セット。OPTIMIZE TABLEの後、TTFBとバックエンドの待ち時間は、機能が失敗することなく見えるようになった。その後、アンインストール後に残ったプラグインの残骸を減らしました。新しい測定では、オートロードの合計が2MB近くになり、ページが明らかに高速化された。すべてのアクションは測定可能で、元に戻すことができ、そしてすぐに次のような結果をもたらしました。 メリット.

コア・オプションと典型的な落とし穴

明らかなチャンクに加えて、特に注意して扱うべきオプションがある。以下のようなものだ。 サイトURL, ホーム, アクティブ・プラグイン, スタイルシート/テンプレート, パーマリンク構造, rewrite_rules, cron そして wp_user_roles. .その中には大きなものもある（例えば。. rewrite_rules)であり、しばしばautoload=’yes'である。私はそれらのサイズを小さくしますが、それらを切り離します。 ない オートロードから不注意に異常に大きい rewrite_rules カスタム投稿タイプ、タクソノミー、プラグインを独自のリライトでチェックし、症状だけに対処するのではなく、整頓しています。それは cron に切り替えるだけです。 autoload=no が発動する。 原因 ではない。.

開発者のベストプラクティスオプションを正しく使う

オートロードの問題の多くは、開発中にすでに生じている。私のガイドライン

  • のエフェメラルデータ（キャッシュ、結果、一時リスト）。 トランジェント また、可能であればオートロードは行わないこと。.
  • メガバイト・サイズの „コレクション・コンテナ “は使わない。.
  • add_option( $name, $value, '', 'no' ) すべてのリクエストに何かが必要でなければ。.
  • なし 過去ログ オプションにデバッグダンプを追加することもできる。.
  • 直列化された巨大な配列の代わりに、いくつかのオプションに切り替えるか、必要に応じて別のテーブルに切り替える。 部分ローディング.
  • 厳密な無効化：「すべてクリア」ではなく、キャッシュを特別に削除する。これにより、データを小さく安定させることができる。.
// 例: オートロードなしで意図的にオプションを作成する
add_option( 'my_plugin_cache', $data, '', 'no' )；

// 巨大な配列が不必要に大きくならないようにする
update_option( 'my_plugin_cache', array_slice( $data, 0, 1000 ), false )；;

オブジェクト・キャッシュ：利点と限界

永続的なオブジェクト・キャッシュ（Redis/Memcached）はデータベースの負荷を軽減するが、次のような問題は解消しない。 オートロード-ブロート. .大きなオートロードの合計は、キャッシュから直接 PHP のメモリに移動します。これはクエリを節約しますが、RAM の必要量とデシリアライズ作業は増加します。したがって、以下のようになります。 減らす, 次にキャッシュ。クリーンアップ後、キャッシュを一度空にし、クリーンでより小さなデータレコードが作成されるようにする。.

wp_optionsのインデックス、エンジン、整合性

デフォルトでは、意味のあるインデックスは オプション名 そして autoload. .手動で移行したインストールでは、これらが削除されたり破損したりすることがあった。私はインデックスをチェックし、必要であればリセットします。また、InnoDBにも注意を払っている。 ストレージエンジン また、大きな値を効率的にスワップアウトできるように、適切な行のフォーマットも用意されている。.

-- インデックスをチェックする
SHOW INDEX FROM wp_options；

-- オートロードに新しいインデックスを作成する。
CREATE INDEX autoload ON wp_options (autoload)；

-- (オプション) InnoDBと最新の行フォーマットに切り替える。
ALTER TABLE wp_options ENGINE=InnoDB, ROW_FORMAT=DYNAMIC；;

重要：構造的な変更は、バックアップとメンテナンスのウィンドウを使ってのみ行ってください。多くの場合、オートロード削減プラス OPTIMIZEテーブル, 大きな効果を得るために。.

再起をかけたトラブルシューティング：測定可能なアプローチを取る

変更後、私は特にリクエストごとに次の主要な数値を監視しています：TTFB、クエリーカウント/時間、ピークメモリー、PHP実行時間。詳細な分析を行うには、データベースのスロークエリログを短時間アクティブにし、開発環境ではプロファイラを有効にする価値があります。すべての変更を分析することが重要です。 絶縁 まずトランジェント、次に個々の大型オプション、そしてテーブルのメンテナンス。.

-- 例：オートロードオプションのクエリーをログに表示する
SET GLOBAL slow_query_log = 1；
SET GLOBAL long_query_time = 0.2; -- 200ms
-- テストの後、再び無効にする

特殊なケースWooCommerce、SEO、統計プラグイン

Eコマースやアナリティクスのプラグインは、しばしば大きなオプション（商品インデックス、レポート、履歴）を生成します。キャッシュの再構築が可能かどうか、キャッシュサイズの設定があるかどうか、特定のレポート機能が本当に常に必要かどうかをチェックする。WooCommerceでは、セッションとインベントリのトランジェントを見てみる価値がある。SEOプラグインでは、インデックスとメタデータのキャッシュに注意を払う。原則 機能維持、メモリー制限 - 巨大な値を恒久的に自動ロードするよりも、より頻繁に再生成する方がよい。.

ステージング、ロールアウト、繰り返し可能なチェック

私は、リスクの高いステップをすべて、最初に実行する。 ステージング環境 そしてそこに特定の一連のコマンドを保存する。そして、このプレイブックを本番に導入する。私は定期的なチェックのために2つのミニレポートを作成する。こうすることで監視を軽量に保ち、プラグインのアップデートでオートロード量が再び増えたときに素早く対応できるようにしている。.

#クイックレポート1：サイズと数
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';"
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';"

#クイックレポート2：トップ10
wp dbクエリ"
SELECT オプション名, ROUND(LENGTH(option_value)/1024/1024,2) AS mb
FROM wp_options WHERE autoload='yes'
ORDER BY mb DESC LIMIT 10；
"

微調整：マルチサイトとネットワーク全体のデータ

マルチサイトのセットアップでは wp_sitemetaテーブルがある。そこにある大きなエントリーは同じような動作をし、いくつかのサイトを遅くする可能性がある。私は合計と上位のエントリーを測定し、ネットワークごとにクリーンアップとオートロードのシェアを決める。チェックはサイトごとに別々に行い、ローカルな機能が見落とされないようにしている。こうすることで、より大きなネットワークの応答性を保ち、共有サイトを保護することもできる。 リソース.

-- ネットワーク全体のデータをチェックする (マルチサイト)
SELECT SUM(LENGTH(meta_value)) AS network_meta_size FROM wp_sitemeta；
SELECT meta_key, LENGTH(meta_value) AS len
FROM wp_sitemeta
ORDER BY len DESC
LIMIT 10；;

構造化実現のためのさらなる支援

ステップ・バイ・ステップで実施したい場合は、コンパクトな ガイド 自分のメモの補足として。測定から始め、バックアップを保存し、トランジェントをクリーンアップしてから、主要なオプションを徐々にチェックしていく。こうすることで、リスクを管理しやすくし、各ラウンド後に明確な改善を確認することができます。この概要は、さらなる構造を提供する： wp_optionsの最適化. .このグリッドがあれば、一貫性を保つことができる。 ステップ 見えないところで.

簡単な要約：高速ページのための最も重要なレバー

自動的にロードされるオプションを常に小さく保ち、トランジェントを整頓し、めったに使われないチャンクを autoload=no そしてテーブルを最適化する。各ラウンドの前後に測定することで、効果が目に見えるようになり、安心感が生まれる。明確なしきい値があれば、数分で最大の原因を見つけ、まずそこから始める。簡単なモニタリングで、オートロードの合計が後で再び上がるのを防ぎます。こうして私は、WordPressのインストールを恒久的にスピードアップさせ、WordPressを強化するのです。 パフォーマンス 目につく。

現在の記事