`wp_options` 物理構造の病理と解剖：Autoload メモリ爆発の回避と決定論的クリーンアップ・エンジニアリング
WordPressのシステムアーキテクチャにおいて、`wp_options` テーブルは最も柔軟であり、同時に最も設計上の欠陥が露出する単一障害点（SPOF）になり得るストレージ領域です。
モノリシックなWordPressコアのブートストラップシークエンスにおいて、`wp_options` は単なるキー・バリューストアではありません。適切なチューニングを怠れば、PHPランタイムのメモリ空間を直接汚染し、InnoDB Buffer Poolをキャッシュ無効化の嵐に巻き込む「暗黒の集積所」へと変貌します。
本稿では、`wp_options` の物理構造、WordPressブート時のメモリ割り当てメカニズム、そしてパッシブなGarbage Collection（GC）構造が抱える本質的な問題を低レイヤの視点から解剖します。その上で、本番環境のデータベースを安全かつ超高速に正常化する、プロダクションレベルのメンテナンスエンジニアリングを提示します。
—
1. `wp_load_alloptions()` の内部メカニズムとメモリ物理学
WordPressがリクエストを受信すると、`wp-settings.php` の初期化プロセス内で `wp_load_alloptions()` が呼び出されます。この関数は、データベース上の `wp_options` テーブルから `autoload = ‘yes’`（または WordPress 6.6 以降の `’auto’`, `’auto-on’`）とマークされたすべての行を単一のSQLクエリで一括取得します。
— wp_load_alloptions() が発行する実際の物理クエリパターン
SELECT option_name, option_value
FROM wp_options
WHERE autoload IN ( ‘yes’, ‘on’, ‘auto-on’, ‘auto’ );
この仕様の背後にあるアーキテクチャ的意図は「データベースのI/Oラウンドトリップ回数の削減」です。しかし、この設計はスケールアウト時に深刻なサイドエフェクトを引き起こします。
メモリ空間における病理
1. PHP Runtime の Allocator 圧迫
取得されたデータは、すべてのリクエストにおいてPHPのハッシュテーブル（配列）としてメモリ上に展開されます。`option_value` に巨大なシリアライズ済みオブジェクトや配列（例: プラグインのログ、一時キャッシュ、巨大なリダイレクトルール）が含まれていた場合、ZENDエンジンはリクエストごとにメガバイト単位の `zval` 領域を確保・解放することになります。これにより、PHP-FPMワーカーのピークメモリ（`memory_get_peak_usage()`）が跳ね上がり、Opcacheの割り当て効率を悪化させます。
2. InnoDB Buffer Pool の汚染とB+Treeページ分割
`wp_options` の物理構造において、`option_value` カラムは `LONGTEXT` 型（最大4GB）で定義されています。InnoDBストレージエンジンでは、データページ（デフォルト16KB）に収まらない巨大な `LONGTEXT` データは Overflow Page（Off-Page） に格納されます。
Autoloadデータが巨大化すると、クエリ実行時に大量のOverflow PageがディスクまたはBuffer Poolから呼び出され、ホットな `wp_posts` や `wp_postmeta` のB+Treeインデックスページが Buffer Pool から追い出される（LRUキャッシュの退避）現象が発生します。
—
2. Transient API の構造的欠陥と Passive GC の限界
Transient API（`set_transient`, `get_transient`）は、オブジェクトキャッシュが利用できない環境におけるフォールバックとして `wp_options` を利用します。 Transientは以下の2つのオプションペアとしてデータベースに物理記録されます。
- `_transient_{$transient_name}` : 値本体
- `_transient_timeout_{$transient_name}` : 期限切れUNIXタイムスタンプ
なぜ Transient は残留し続けるのか？（Passive Evictionの罠）
WordPressコアの Transient 破棄メカニズムは完全な受動型（Passive Eviction）です。
[ Request ] ──> get_transient(‘foo’) ──> タイムスタンプ判定 ──> [ 期限切れの場合のみ DELETE 発行 ]
つまり、二度と呼び出されない Transient は、永遠に `wp_options` 内に留まり続けます。
さらに悪名高い問題として、一部の粗悪なプラグインや古いコードは Transient を作成する際に `autoload` フラグを明示的に制御せず、デフォルトの `’yes’` で書き込みます。結果として、「すでに期限切れとなった無効なキャッシュデータが、毎リクエストの `wp_load_alloptions()` によってメモリへ強制ロードされる」 という最悪のミスマッチが発生します。
—
3. SQLによる物理診断：クエリレベルの外科的手術
トラブルシューティングの第一歩は、GUIプラグインに頼ることなく、直接MySQLプロトコル経由でデータベースの物理サイズと異常値を定量計測することです。
診断 1: Autoload データの総物理バイト数計測
SELECT
SUM(LENGTH(option_value)) AS total_autoload_bytes,
COUNT() AS total_autoload_keys,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS total_autoload_mb
FROM
wp_options
WHERE
autoload IN (‘yes’, ‘on’, ‘auto-on’, ‘auto’);
アーキテクトの基準値: `total_autoload_mb` が 1.00 MB を超えている場合、即座に介入が必要です。理想値は 300KB 以下です。
診断 2: メモリを圧迫しているワースト Autoload オプションの特定
SELECT
option_name,
LENGTH(option_value) AS option_size_bytes,
ROUND(LENGTH(option_value) / 1024, 2) AS option_size_kb
FROM
wp_options
WHERE
autoload IN (‘yes’, ‘on’, ‘auto-on’, ‘auto’)
ORDER BY
option_size_bytes DESC
LIMIT 20;
診断 3: 孤立・期限切れ Transient の死骸の計測
SELECT
COUNT() AS expired_transients_count,
ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS reclaimable_kb
FROM
wp_options
WHERE
option_name LIKE ‘_transient_timeout_%’
AND CAST(option_value AS UNSIGNED) < UNIX_TIMESTAMP();
---
4. プロダクション環境用 決定論的クリーンアップ・エンジン
以下は、大容量データベース環境でもロック時間を最小限に抑え、安全に `wp_options` を正常化するための WP-CLI カスタムコマンド・実装コードです。
WordPressの `get_option()` や `delete_option()` のようなハイレベルAPIをそのままループ内で大量呼び出しすると、内部の `alloptions` キャッシュ再構築ロジックが走り、PHPのメモリが溢れます。そのため、本スクリプトでは `$wpdb` によるチャンク単位の直接SQLトランザクション制御とオブジェクトキャッシュの明示的無効化を組み合わせています。
カスタム WP-CLI コマンドの実装
以下のコードを、メンテナンス用カスタムプラグインまたはテーマの `functions.php`（開発環境/CLIコンテキスト）に組み込みます。
/
if (!defined(‘WP_CLI’) || !WP_CLI) {
return;
}
class Enterprise_Options_Optimizer_Command {
/
- wp_options の物理クリーンアップと Autoload 最適化を実行する
-
OPTIONS
- [–max-bytes=
] - : AutoloadをOFFにする単一オプションのバイト数閾値（デフォルト: 102400 = 100KB）
- default: 102400
- [–dry-run]
- : 実際の削除・更新を行わず、影響を受けるレコードの試算のみ行う
-
EXAMPLES
- wp options-optimize run –max-bytes=51200 –dry-run
- wp options-optimize run
/
public function run($args, $assoc_args) {
global $wpdb;
$max_bytes = (int) $assoc_args[‘max-bytes’];
$dry_run = isset($assoc_args[‘dry-run’]);
WP_CLI::line(WP_CLI::colorize(‘%Y[System Initialization]%n Starting wp_options physical analysis…’));
// 1. 期限切れ Transient の直接一括削除 (Active Garbage Collection)
$this->purge_expired_transients($dry_run);
// 2. 孤立した Transient（Timeoutが存在しない本体）の破棄
$this->purge_orphaned_transients($dry_run);
// 3. 巨大な Autoload オプションの Autoload フラグ解除 (autoload -> ‘no’)
$this->demote_oversized_autoloads($max_bytes, $dry_run);
// 4. WordPress コア Object Cache のクリア
if (!$dry_run) {
wp_cache_flush();
WP_CLI::success(‘Object cache flushed successfully.’);
}
WP_CLI::success(‘Optimization engine execution completed.’);
}
/
- 期限切れ Transient のバッチ破棄
/
private function purge_expired_transients(bool $dry_run) {
global $wpdb;
WP_CLI::line(‘Analyzing expired transients…’);
// 期限切れ Timeout オプションの取得
$now = time();
$expired_timeouts = $wpdb->get_results(
$wpdb->prepare(
“SELECT option_name, option_value FROM {$wpdb->options}
WHERE option_name LIKE %s AND CAST(option_value AS UNSIGNED) < %d",
'_transient_timeout_%',
$now
)
);
if (empty($expired_timeouts)) {
WP_CLI::line('No expired transients found.');
return;
}
$count = count($expired_timeouts);
WP_CLI::line(sprintf('Found %d expired transients.', $count));
if ($dry_run) {
WP_CLI::line("[Dry-Run] {$count} expired transients would be deleted.");
return;
}
$deleted = 0;
// データベースロックを最小化するためのバッチ処理 (Chunking)
$chunks = array_chunk($expired_timeouts, 500);
foreach ($chunks as $chunk) {
$option_names_to_delete = [];
foreach ($chunk as $row) {
$transient_name = substr($row->option_name, strlen(‘_transient_timeout_’));
$option_names_to_delete[] = $row->option_name; // Timeout 自身
$option_names_to_delete[] = ‘_transient_’ . $transient_name; // 本体
$option_names_to_delete[] = ‘_site_transient_timeout_’ . $transient_name;
$option_names_to_delete[] = ‘_site_transient_’ . $transient_name;
}
if (!empty($option_names_to_delete)) {
$escaped_names = implode(“‘,'”, array_map(‘esc_sql’, $option_names_to_delete));
$query = “DELETE FROM {$wpdb->options} WHERE option_name IN (‘{$escaped_names}’)”;
$result = $wpdb->query($query);
if ($result !== false) {
$deleted += $result;
}
}
}
WP_CLI::success(sprintf(‘Purged %d transient option records from DB.’, $deleted));
}
/
- Timeoutを持たない孤立した Transient の破棄
/
private function purge_orphaned_transients(bool $dry_run) {
global $wpdb;
WP_CLI::line(‘Analyzing orphaned transients…’);
$sql = ”
SELECT t1.option_name
FROM {$wpdb->options} t1
LEFT JOIN {$wpdb->options} t2
ON t2.option_name = CONCAT(‘_transient_timeout_’, SUBSTRING(t1.option_name, 12))
WHERE t1.option_name LIKE ‘\_transient\_%’
AND t1.option_name NOT LIKE ‘\_transient\_timeout\_%’
AND t2.option_name IS NULL
“;
$orphans = $wpdb->get_col($sql);
$count = count($orphans);
if ($count === 0) {
WP_CLI::line(‘No orphaned transients found.’);
return;
}
WP_CLI::line(sprintf(‘Found %d orphaned transients.’, $count));
if ($dry_run) {
WP_CLI::line(“[Dry-Run] {$count} orphaned transients would be deleted.”);
return;
}
$chunks = array_chunk($orphans, 500);
foreach ($chunks as $chunk) {
$escaped_names = implode(“‘,'”, array_map(‘esc_sql’, $chunk));
$wpdb->query(“DELETE FROM {$wpdb->options} WHERE option_name IN (‘{$escaped_names}’)”);
}
WP_CLI::success(sprintf(‘Deleted %d orphaned transient records.’, $count));
}
/
- 閾値を超える Autoload オプションのダウングレード（autoload = ‘no’）
/
private function demote_oversized_autoloads(int $max_bytes, bool $dry_run) {
global $wpdb;
WP_CLI::line(sprintf(‘Analyzing autoload options larger than %d bytes…’, $max_bytes));
$targets = $wpdb->get_results(
$wpdb->prepare(
“SELECT option_name, LENGTH(option_value) as bytes
FROM {$wpdb->options}
WHERE autoload IN (‘yes’, ‘on’, ‘auto-on’, ‘auto’)
AND LENGTH(option_value) > %d
ORDER BY bytes DESC”,
$max_bytes
)
);
if (empty($targets)) {
WP_CLI::line(‘No oversized autoload options detected.’);
return;
}
foreach ($targets as $target) {
// Coreの必須オプションは除外する安全装置 (Whitelist Protection)
if ($this->is_protected_core_option($target->option_name)) {
WP_CLI::line(WP_CLI::colorize(“%C[Skip Core Protected]%n {$target->option_name} ({$target->bytes} bytes)”));
continue;
}
WP_CLI::line(sprintf(
‘Oversized Autoload Target: %s (%s KB)’,
$target->option_name,
round($target->bytes / 1024, 2)
));
if (!$dry_run) {
// WordPress 6.6 互換を考慮し ‘no’ または ‘off’ に変更
$wpdb->update(
$wpdb->options,
[‘autoload’ => ‘no’],
[‘option_name’ => $target->option_name],
[‘%s’],
[‘%s’]
);
}
}
if ($dry_run) {
WP_CLI::line(‘[Dry-Run] Autoload flag modifications were skipped.’);
} else {
WP_CLI::success(‘Oversized autoload flags have been updated to “no”.’);
}
}
/
- コア動作に必要な絶対保護対象オプションの検証
/
private function is_protected_core_option(string $option_name): bool {
$whitelist = [
‘siteurl’,
‘home’,
‘blogname’,
‘template’,
‘stylesheet’,
‘active_plugins’,
‘rewrite_rules’,
‘cron’,
‘whitelist_options’
];
return in_array($option_name, $whitelist, true);
}
}
WP_CLI::add_command(‘options-optimize’, ‘Enterprise_Options_Optimizer_Command’);
コマンドの実行
1. 影響確認（ドライラン）: 50KBを超えるAutoloadデータを抽出
$ wp options-optimize run –max-bytes=51200 –dry-run
2. 本番適用（トランザクション処理＋一括破棄）
$ wp options-optimize run –max-bytes=102400
—
5. データベース物理デフラグメンテーションと Redis の運用設計
大量のデッドコードや Transient を削除した直後の MySQL ディスク空間には、B+Tree ページの空洞化（ページフラグメンテーション）が発生しています。
`DELETE` 文を実行しても、物理ディスク上のファイルサイズ（`wp_options.ibd`）は小さくなりません。InnoDBの空き領域（`Data_free`）としてテーブル内部に保持されるだけです。
物理領域の完全解放：`OPTIMIZE TABLE` の慎重な執行
物理ディスク領域をオペレーティングシステムに返却するには、テーブルの再構築（Rebuild）が必要です。
— 物理デフラグメンテーションの実行 (テーブルロックに注意)
OPTIMIZE TABLE wp_options;
> アーキテクトの注意点:
> InnoDBにおける `OPTIMIZE TABLE` は、内部的に `ALTER TABLE wp_options ENGINE=InnoDB` に書き換えられます。これはテーブルのコピーを作成して物理ページを最小化して詰め直す処理（Online DDL）です。大量のリクエストが走る本番環境で実行する場合、一時的なI/Oスパイクとテーブルメタデータロック（MDL）が発生するため、トラフィックの少ないメンテナンスウィンドウでのみ実行してください。
—
6. アーキテクチャレベルの予防策
クリーンアップスクリプトは対症療法に過ぎません。システムアーキテクトとしては、`wp_options` の肥大化を根本から防ぐ設計ルールを設ける必要があります。
1. Persistent Object Cache (Redis / Memcached) の導入
Redis Object Cache を導入すると、Transient は `wp_options` テーブルではなく Redis のインメモリ空間に直接格納され、TTL（Time To Live）に基づき Redis のネイティブ eviction アルゴリズム（Volatile-LRU 等） によって完全に物理削除されます。これにより、データベース上の Transient 汚染は根本から絶たれます。
2. コードレビュー規約の強制
プラグインやテーマの開発時、`add_option()` または `update_option()` を呼び出す際は、第3引数（`autoload`）に明示的に `$autoload = false` （または `’no’`）を指定することをCI/CDの静的解析（PHP_CodeSniffer 等）で強制します。
// BAD: デフォルトで autoload = ‘yes’ になり、メモリを圧迫する
update_option(‘my_heavy_plugin_state’, $large_array);
// GOOD: 明示的に autoload を無効化。必要なコンテキストでのみ get_option() で読み込む
update_option(‘my_heavy_plugin_state’, $large_array, false);
3. `wp_set_option_autoload()`（WP 6.4+）の積極活用
モダンなWordPressコアには、個別のオプション値のサイズに応じて動的に Autoload 状態を変更する関数が導入されています。大容量の構造化データを保存する処理では、保存時にバイト数を検証し、動的に Autoload フラグをコントロールする制御ロジックを実装してください。
—
結論
`wp_options` テーブルの管理は、単なる「不要データの削除」ではなく、PHPランタイムのメモリ物理学と RDBMS の I/O パフォーマンスを最適化するシステム工学です。
1. Autoload データ容量を物理的に制限する（理想は 300KB 以下）。
2. 受動的な GC に依存せず、CLIレベルで直接かつ高速なバッチ削除（Active GC）を定期実行する。
3. Redis 導入による Transient のメモリ空間への完全オフロード。
この3原則を堅牢なインフラ構成とビルドパイプラインに組み込むことで、どれほどスケールしたWordPressシステムであっても、物理層からのパフォーマンス劣化を永久に防止することが可能となります。