WordPressの「見えない首輪」：`wp_options`テーブルの`autoload=yes`があなたのサイトを殺す理由
こんにちは。WordPressの深淵を覗く旅へようこそ。
多くの開発者がWordPressのパフォーマンスに悩むとき、真っ先にキャッシュプラグインを入れようとします。しかし、それは「痛み止め」を飲んでいるだけで、病巣を見逃している可能性が高い。
今日は、WordPressの心臓部である`wp_options`テーブル、特に`autoload=yes`という設定が、いかにしてあなたのアプリケーションのメモリを食いつぶし、リクエストのたびに「見えない重石」として機能しているのかを解き明かしましょう。
—
1. `autoload=yes` とは何か？
WordPressは、管理画面で設定を変更したり、プラグインを有効化したりするたびに、そのデータを`wp_options`テーブルに保存します。このとき、重要なのが `autoload` カラムです。
ここが `yes` になっているデータは、WordPressが起動するたび（`wp_load` の瞬間）に、無条件で全件メモリ上にロードされます。
メモリ上のイメージ図
[ リクエスト開始 ]
↓
[ wp_options から autoload=yes の全データを取得 (SELECT FROM wp_options WHERE autoload = ‘yes’) ]
↓
[ PHPのメモリ上に配列として展開 (ここでデシリアライズ処理が走る) ]
↓
[ ページ生成開始 ]
もし、あなたが100個のプラグインを入れていて、それぞれが大きな配列を`autoload=yes`で保存していたらどうなるでしょう？ ページを表示するたびに、数メガバイトのデータをメモリ上で復元するコストが発生します。これが「サイトが重い」の正体の一つです。
—
2. なぜ「シリアライズ」がコストになるのか
WordPressのデータベースには、PHPの配列やオブジェクトを文字列に変換した「シリアライズデータ」が大量に格納されています。
- シリアライズ前: `[‘theme_options’ => [‘color’ => ‘blue’, ‘font’ => ‘sans-serif’]]`
- DB保存時: `a:1:{s:13:”theme_options”;a:2:{s:5:”color”;s:4:”blue”;s:4:”font”;s:10:”sans-serif”;}}`
DBから取り出した後、PHPは `unserialize()` 関数を実行してこれを元の配列に戻します。この「復元作業」にはCPUとメモリリソースを直接消費します。 巨大なシリアライズデータが`autoload=yes`で読み込まれると、ただのテキスト処理だけで数ミリ秒〜数十ミリ秒のラグが生じるのです。
—
3. 現状を可視化する（あなたのサイトの健康診断）
まずは、自分のサイトがどれだけの「重石」を背負っているかを確認してみましょう。以下のSQLをphpMyAdminやWP-CLIで実行してみてください。
— autoload=yes のデータサイズ合計を表示 (KB単位)
SELECT
SUM(LENGTH(option_value)) / 1024 AS autoload_size_kb
FROM wp_options
WHERE autoload = ‘yes’;
— 特に巨大なデータを持っている犯人を探す
SELECT
option_name,
LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = ‘yes’
ORDER BY size_bytes DESC
LIMIT 10;
もし `autoload_size_kb` が 800KB を超えていたら、要注意です。それは立派なパフォーマンス低下の原因です。
—
4. 対策：`autoload` を制御する
「じゃあ、全部 `no` にすればいいの？」というと、そうではありません。頻繁に使うデータ（サイトURLやテーマ設定など）はロードした方が効率的です。
重要なのは、「本当に全リクエストで必要か？」を自問自答することです。
開発者として覚えておくべきAPI
WordPressの `update_option()` 関数には、実は第4引数で `autoload` を制御するフラグがあります。
// 間違った例：デフォルトのままだとautoload=yesになり、肥大化を招く
update_option( ‘my_plugin_huge_data’, $huge_array );
// 正しい例：全リクエストで必要ないなら ‘no’ を指定する
update_option( ‘my_plugin_huge_data’, $huge_array, false );
この第3引数（`autoload`）に `false` を渡すだけで、そのデータは必要な時に `get_option()` を呼んだ時だけDBへアクセスされるようになります。
—
5. まとめ：ここをクリアすれば「プロ」への一歩
WordPressのパフォーマンスチューニングとは、「いつ、何をメモリに乗せるか」を制御することに他なりません。
1. 無闇に `autoload=yes` にしない: 巨大なデータは必ず `false` を指定する。
2. 不要なオプションを削除する: アンインストール時に `delete_option()` を呼び出し、ゴミを残さない実装をする。
3. DBスキーマを理解する: `wp_options` は設定値の集まりであり、ログやキャッシュ置き場ではないことを肝に銘じる。
ここを意識するだけで、あなたの作るWordPressサイトは、他の凡庸なサイトとは一線を画す「爆速で安定したアプリケーション」に生まれ変わります。
最初は難しく感じるかもしれませんが、DBの構造が見えてくるとWordPressはもっと面白くなりますよ。一つずつ、確認していきましょうね。応援しています。