階層の深淵：`wp_posts.post_parent` が引き起こす計算複雑性と、再帰的クエリを無効化する戦略
WordPressのデータベース設計は、20年前のWebの標準的な要件から出発している。この構造上の負債が、現代の大規模トラフィック下でどのように牙を剥くか。特に `post_parent` を用いた階層構造の再帰的取得は、RDBMSのコンテキストにおいて最も回避すべき「アンチパターン」の一つだ。
本稿では、`wp_posts` の物理構造を解剖し、なぜ再帰的クエリがスケーラビリティを破壊するのか、そして我々がどのようにしてこのボトルネックをキャッシュレイヤーで制圧すべきかを論じる。
—
1. 物理構造の脆弱性：なぜ `post_parent` は悪夢なのか
`wp_posts` テーブルは、Adjacency List（隣接リスト）モデルを採用している。このモデルにおける再帰的クエリは、SQLレベルで解決しようとすると指数関数的な計算量を要求する。
MySQL/MariaDBにおいて、`WHERE post_parent = X` というクエリを投げ続ける再帰処理は、以下のコストを発生させる。
1. I/Oオーバーヘッド: インデックスが貼られていたとしても、階層の深さ（Depth）に比例した数のインデックスルックアップとデータページ読み込みが発生する。
2. クエリの累積: 実行計画（Execution Plan）の最適化が困難であり、キャッシュミスが起きた瞬間にデータベースのコネクションプールを枯渇させる。
3. ロックの競合: 大規模環境では、このReadクエリが意図しない行ロックや、ギャップロックの影響を受け、書き込み処理をブロックする要因となる。
—
2. 禁忌の再帰を排除する：メタデータによるフラット化とキャッシュ戦略
再帰を避けるための王道は、「階層情報を非正規化（Denormalize）してメタデータに埋め込むこと」である。
戦略：Path Enumerationの適用
階層を `{ancestor_1}/{ancestor_2}/{target_id}` のような文字列として保存する。これにより、再帰処理は `LIKE` 演算子による単純な前方一致検索へと変換される。
/
- 投稿保存時に階層パスを生成し、メタデータに書き込む
- 再帰的なSQL実行を回避するための設計
/
add_action(‘save_post’, function($post_id, $post) {
if ($post->post_type !== ‘my_hierarchical_type’) return;
$path = ($post->post_parent > 0)
? get_post_meta($post->post_parent, ‘_hierarchy_path’, true) . ‘/’ . $post->post_parent
: ‘root’;
update_post_meta($post_id, ‘_hierarchy_path’, $path);
}, 10, 2);
—
3. オブジェクトキャッシュへの「再帰的構造」の投射
データベースへのクエリそのものを実行するのではなく、アプリケーション起動時にメモリレイヤー（Redis/Memcached）へ構造を写像する。これが真のパフォーマンス最適化だ。
以下のコードは、階層構造をRedis上に単一のハッシュマップとして保持し、計算量を $O(1)$ に収束させるためのアプローチである。
class HierarchyManager {
/
- キャッシュから階層構造をメモリへロード
- O(N)の再帰ではなく、O(1)のキー参照で解決する
/
public static function get_children_flat($parent_id) {
$cache_key = “hierarchy_map_{$parent_id}”;
$data = wp_cache_get($cache_key, ‘hierarchy’);
if (false === $data) {
global $wpdb;
// 物理インデックスを利用した単一クエリで全リーフを取得
$data = $wpdb->get_results($wpdb->prepare(
“SELECT ID FROM {$wpdb->posts} WHERE post_parent = %d”,
$parent_id
));
wp_cache_set($cache_key, $data, ‘hierarchy’, HOUR_IN_SECONDS);
}
return $data;
}
}
—
4. チーフアーキテクトの視点：アーキテクチャの生存戦略
大規模WordPressサイトにおいて、`wp_posts` の階層構造に依存することは、システムの「時限爆弾」を抱えることと同義である。
- 物理メモリの最適化: `wp_postmeta` はEAV（Entity-Attribute-Value）モデルであり、肥大化するとJoinが地獄と化す。階層パスのような検索頻度の高いデータは、独自のカスタムテーブルへ切り出すことを推奨する。
- クエリの強制終了: 実行時間が100msを超えるような再帰クエリが走った場合、即座に `SAVEPOINT` やクエリキャンセルを行う監視エージェントをアプリケーション層に組み込むべきだ。
- キャッシュの妥当性: `save_post` フックでのキャッシュパージは必須だが、階層が深い場合、子孫ノードすべてをパージすると書き込み負荷が跳ね上がる。これを防ぐために、キャッシュのTTLを短く設定し、読み込み遅延を許容する「Stale-While-Revalidate」パターンの導入を検討せよ。
結論
WordPressのコアは汎用性を優先したがゆえに、特定のデータ構造において最適化を怠っている。我々エンジニアの仕事は、その不完全なスキーマを理解した上で、メモリレイヤーや非正規化テーブルを駆使し、「データベースを叩かないことが最大の高速化である」という原則を貫くことにある。
階層の深淵を覗くとき、深淵もまたこちらを覗いている。その深淵をSQLで処理しようとするのは、エンジニアとしての敗北であると心得よ。