【入門編】wp_optionsテーブルのautoload=yesが引き起こすボトルネックの特定と排除 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

こんにちは！WordPressの裏側の仕組みを紐解く旅へようこそ。

他の言語（Ruby、Python、Node.jsなど）からWordPressの世界へやってくると、その手軽さに驚く一方で、「なんだかサイト全体の動作が重いな…」「データベースのクエリがやたらと多いな…」と感じたことはありませんか？

そのパフォーマンス低下の元凶、実はデータベースの`wp_options` テーブル、そしてその中にある `autoload = ‘yes’` という設定に隠されていることが多いんです。

今回は、この `autoload` の正体を暴き、肥大化したオプションデータを華麗に整理して、WordPressサイトを爆速化させる極意を一緒にマスターしていきましょう！ここをクリアすれば、あなたも立派なWordPressパフォーマンスチューナーの仲間入りですよ。

—

1. なぜ `wp_options` の `autoload = ‘yes’` がボトルネックになるのか？

まずは、WordPressの心臓部であるデータベース構造を少しだけ覗いてみましょう。

`wp_options` テーブルは、サイト全体の環境設定やプラグインの設定値など、「単一のキーとバリュー（Key-Value）」のデータを保存するための場所です。このテーブルには、以下のようなカラムが存在します。

  • `option_id`: 一意のID
  • `option_name`: オプション名（例: `siteurl`, `active_plugins` など）
  • `option_value`: 設定値（シリアライズされたデータも含む）
  • `autoload`: ここが今回の主役！ (`yes` または `no`)

🧠 内部コアの挙動：何が起きているのか？

WordPressは、リクエストが飛んできたちょっとその瞬間（具体的には `WP_Load` の初期化プロセス、`wp-settings.php` の読み込み時）に、次のようなSQLを無条件で実行しています。

SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’;

お気づきでしょうか？ ページの内容が何であろうと、トップページだろうが、お問い合わせフォームだろうが、管理画面だろうが関係なく、`autoload = ‘yes’` が設定されたすべての行が、一度のクエリでメモリ上にロードされるのです。

もし、使われなくなった古いプラグインがこの場所に数メガバイトものゴミデータを残していたら……？ ページが表示されるたびに、PHPのメモリ（`memory_limit`）とデータベースのI/Oが無駄に消費され続けることになります。これが、「autoload地獄」の正体です。

—

2. 現在の autoload データを計測する

まずは、自分のサイトがどれくらい `autoload` データを抱え込んでいるのか、実態を把握することから始めましょう。

以下のコードを、自作プラグイン内や、テーマの `functions.php`（またはWP-CLIなど）で実行してみましょう。

  • 現在の autoload データの総容量（バイト数）を計測するスニペット

    • /
    function check_autoload_options_size() {
    global $wpdb;

    // autoload = ‘yes’ のオプション名と、その長さを計算して取得
    $results = $wpdb->get_results( “SELECT option_name, LENGTH(option_value) as option_size FROM {$wpdb->options} WHERE autoload = ‘yes'” );

    $total_size = 0;
    $count = 0;
    $heavy_options = [];

    foreach ( $results as $row ) {
    $size = (int) $row->option_size;
    $total_size += $size;
    $count++;

    // 10KB以上の重たいオプションをピックアップ
    if ( $size > 10240 ) {
    $heavy_options[] = [
    ‘name’ => $row->option_name,
    ‘size’ => round( $size / 1024, 2 ) . ‘ KB’
    ];
    }
    }

    // 結果をログに出力（実運用では権限チェックを必ず入れてくださいね）
    error_log( ‘— WordPress Autoload 診断結果 —‘ );
    error_log( ‘総autoload項目数: ‘ . $count );
    error_log( ‘autoload総容量: ‘ . round( $total_size / 1024 / 1024, 2 ) . ‘ MB’ );
    error_log( ’10KBを超える重量級オプション: ‘ . print_r( $heavy_options, true ) );
    }

    // 管理画面の特定のタイミングなどで一度だけ実行して確認してみましょう
    add_action( ‘admin_init’, ‘check_autoload_options_size’ );

    💡 コードのポイント

    • `LENGTH(option_value)` を使うことで、データベース上で実際にその値が消費しているバイト数を正確に測ることができます。
    • もしここで autoloadの総容量が 1MB を大きく超えている場合 は、危険信号です。即座に対策を講じる必要があります。

    —

    3. 不要なデータを `autoload = ‘no’` へ分離する

    原因が分かったら、次は処置です。「毎回読み込む必要のないデータ」は、すべて `autoload = ‘no’` に変更してしまいましょう。

    WordPressには、オプションの値を更新する `update_option()` という非常に便利な関数があります。実はこの関数、第4引数に `$autoload` を指定できるのを知っていましたか？

    update_option( $option_name, $option_value, $autoload );

    実践：重たいオプションを `no` に変更する

    例えば、あるプラグインがキャッシュデータを誤って `wp_options` に保存しており、それがautoload対象になってしまっている場合、次のように明示的に `no` へ変更します。

  • 特定のオプションの autoload を無効化（no）にする安全な手順

    • /
    function fix_heavy_autoload_option() {
    $option_name = ‘some_heavy_transient_or_cache’; // 対象のオプション名

    // 現在の値を取得
    $current_value = get_option( $option_name );

    if ( false !== $current_value ) {
    // 第3引数に ‘no’ を指定して更新する！
    // これで次回のリクエストからメモリに自動ロードされなくなります。
    update_option( $option_name, $current_value, ‘no’ );

    echo ‘

    成功: ‘ . esc_html( $option_name ) . ‘ の autoload を off にしました！

    ‘;
    } else {
    echo ‘

    注意: 指定されたオプションは存在しません。

    ‘;
    }
    }

    // 例として管理画面に通知を出すフックなどに組み込むことができます
    // add_action( ‘admin_notices’, ‘fix_heavy_autoload_option’ );

    —

    4. 陥りやすい罠と文法エラー

    初心者の方がよくやってしまうミスや、現場でハマりがちなポイントをいくつかシェアしておきますね。

    ⚠️ 罠1: `add_option()` や `update_option()` の引数順序の勘違い

    WordPressの関数は歴史が長いため、バージョンによって微調整が入っています。
    古いコードやネット上の古い記事を見ると、第4引数が `autoload` ではなく、単なる「自動ロードするかどうか（ブール値）」だった時代（WordPress 4.2以前など）の名残を見かけます。
    現代のWordPress（4.2以降）では、第3引数に自動ロードの有無（`’yes’` または `’no’` ※厳密には文字列、または真偽値）を指定するのが仕様です。最新の公式ドキュメントを意識する癖をつけましょう。

    ⚠️ 罠2: 動的に生成されるオプション名への過信

    プラグインによっては、プレフィックスやハッシュ値を含んだ動的なオプション名を生成するものがあります。これらをコードで一つずつ `no` に変更するのは大変なので、データベースを直接操作したくなる誘惑に駆られます。

    もし直接SQLを叩く場合は、必ずトランザクションやバックアップを挟み、以下のように慎重に行ってください。

    — 例：特定のプレフィックスを持つオプションのautoloadを一括で ‘no’ にする（※実行は自己責任で！）
    UPDATE wp_options
    SET autoload = ‘no’
    WHERE option_name LIKE ‘plugin_prefix_%’
    AND autoload = ‘yes’;

    ※直接DBをいじる前には、必ずデータベースのバックアップを取るのがプロのエンジニアとしてのマナーですよ！

    —

    まとめ

    今回は `wp_options` テーブルの `autoload = ‘yes’` が引き起こすパフォーマンスボトルネックと、その具体的な対策について解説しました。

    • すべてのページで無条件に読み込まれる `autoload = ‘yes’` は肥大化しやすい。
    • 定期的にコードで容量を計測し、重たいデータを洗い出す。
    • 頻繁に使わないデータやキャッシュは `update_option( $name, $value, ‘no’ )` で華麗に分離する。

    このチューニングを行うだけで、WordPressのレスポンス速度（TTFB: Time to First Byte）が見違えるように改善されるケースがたくさんあります。

    「動くだけのコード」から一歩進んで、こうした内部構造までコントロールできるようになると、WordPressの開発が何倍も楽しく、そして深くなりますよ。
    ここをクリアしたあなたなら、どんな重たいWordPressサイトに出会ってももう怖くありません。ぜひ明日の開発から取り入れてみてくださいね！

    スポンサーリンク
    " "
    タイトルとURLをコピーしました