WordPressの「見えない重荷」を解き放つ：wp_optionsテーブルとautoloadの深淵
こんにちは。WordPressのコアを隅々まで愛するエンジニアです。
皆さんは、WordPressのパフォーマンスを語る時、真っ先に「キャッシュプラグイン」や「画像の最適化」を思い浮かべるかもしれません。しかし、真のプロフェッショナルは、「WordPressがリクエストを受け取った瞬間に何が起きているか」という、極めて静かな、しかし致命的な領域に目を向けます。
今日は、WordPressの心臓部である `wp_options` テーブル、特に `autoload` という仕組みが引き起こす「静かなメモリの枯渇」について、本質から紐解いていきましょう。
—
1. なぜ、あなたのサイトは「重い」のか？
WordPressの `wp_options` テーブルには、サイトの基本設定（URLやタイトル）から、プラグインが保存した複雑なデータまで、あらゆる情報が詰め込まれています。
ここで重要なのが `autoload` カラム です。ここが `’yes’` になっているデータは、WordPressが起動した瞬間にすべてメモリへロードされます。
メモリ枯渇のメカニズム
1. ブートストラップ: PHPが `wp-load.php` を読み込む。
2. 全読み込み: `wp_load_alloptions()` 関数が動き、`autoload=’yes’` の全データをDBから一括取得する。
3. メモリへ展開: そのデータがPHPのメモリ上に展開される。
もし、プラグインが「一時的なログ」や「巨大な配列データ」を `autoload=’yes’` のまま `update_option()` で保存していたらどうなるでしょう？
リクエストのたびに、「サイトの表示には全く必要のない数メガバイトのデータ」が毎回メモリを食いつぶすことになります。これが、大規模サイトで発生する「なぜかレスポンスが遅い」「PHPのメモリ制限（Memory Limit）にすぐ達する」という現象の正体です。
—
2. 犯人を特定する：SQLでの調査
まずは、あなたのサイトで何が起きているか、SQLで覗いてみましょう。MySQLのコンソールやphpMyAdminで以下のクエリを叩いてみてください。
— autoload=’yes’ に設定されているデータの総容量を計算する
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb
FROM wp_options
WHERE autoload = ‘yes’;
もしこの結果が 1MBを超えているなら、黄色信号です。さらに、どのオプションが巨大かを知るにはこちらをどうぞ。
— 容量の大きい順に上位10個を表示する
SELECT option_name, LENGTH(option_value) / 1024 AS size_kb
FROM wp_options
WHERE autoload = ‘yes’
ORDER BY size_kb DESC
LIMIT 10;
—
3. 解決策：autoloadを「no」にする
不要なデータが肥大化している場合、修正は驚くほどシンプルです。`update_option` の第4引数を使います。
悪い例（デフォルト）
// 第4引数を省略すると、デフォルトで ‘yes’ になることがあります
update_option(‘my_plugin_huge_data’, $huge_array);
良い例（必要な時だけ読み込む）
// 第4引数を ‘no’ にすることで、autoload対象から外す
update_option(‘my_plugin_huge_data’, $huge_array, ‘no’);
こうすることで、そのデータは `get_option(‘my_plugin_huge_data’)` をコールした時だけDBに問い合わせが行くようになります。これで、すべてのリクエストが軽くなります。
—
4. 陥りやすい罠：すでに保存されているデータはどうする？
すでにテーブル内に `autoload=’yes’` として保存されているデータは、`update_option` を呼ぶだけでは変更されません。そんな時は、直接データベースを操作するのが最も効率的です。
// 一度だけ実行して、特定のオプションのautoloadを無効にするスクリプト
global $wpdb;
$wpdb->query(
$wpdb->prepare(
“UPDATE {$wpdb->options} SET autoload = ‘no’ WHERE option_name = %s”,
‘my_plugin_huge_data’
)
);
—
5. 最後に：エンジニアとしての視点
WordPressの設計は非常に柔軟ですが、その柔軟性ゆえに「プラグインがやりたい放題データを突っ込む」という側面があります。
- 設定値など、全ページで必須のもの: `autoload=’yes’` でOK。
- 特定のページや管理画面だけで使うもの: 必ず `autoload=’no’` にする。
この意識を持つだけで、あなたのサイトは「動く」レベルから「快適に動作する」レベルへと進化します。
「なぜリクエストの度にこのデータを読み込んでいるのか？」という疑問を常に持つこと。この視点こそが、WordPressを掌握する第一歩です。ここをクリアすれば、あなたはもう、WPコアの挙動をコントロールできる立派なエンジニアですよ。
また次回の講義でお会いしましょう。技術の深淵を一緒に楽しんでいきましょうね。