階層構造の呪縛：wp_posts における再帰的クエリを排除し、データベースの論理的エントロピーを制御する
WordPressの `wp_posts` テーブルは、その柔軟性の代償として、階層構造の表現において致命的なパフォーマンス上の負債を抱えている。`post_parent` を辿る再帰的クエリ（Adjacency List Model）は、階層が深まるにつれ O(N) のクエリコストを発生させ、結果として MySQL の実行計画を破壊し、バッファプールを汚染する。
今日は、我々アーキテクトが大規模サイトを構築する際に避けて通れない、「階層パス（Materialized Path）」の実装によるクエリの定数時間化と、その同期ロジックの極意を伝授する。
—
1. なぜ再帰的クエリはデータベースの敵なのか
`wp_posts` における標準的な親子関係の解決策は、`WHERE post_parent = X` の連続実行だ。深さ N のノードを取得するために N 回のラウンドトリップが発生する。さらに、`get_posts()` や `WP_Query` を安易に再帰呼び出しすれば、PHP 側のオブジェクト生成コストが雪だるま式に増大し、メモリを浪費する。
大規模な環境において、この設計は「死」を意味する。インデックスの走査範囲が広がり、ディスクI/Oがスパイクすることで、他のクエリまで巻き添えを食らうからだ。
2. 「階層パス」による論理構造のフラット化
階層構造を維持しつつ、一発のクエリで「祖先」や「子孫」を引くには、`post_path` カラムを導入するのが定石だ。
- 物理設計: `wp_posts` に `meta_path`（またはカスタムテーブルを作成し、`VARCHAR(255)` 等でパスを保持）を追加。
- 値の形式: `/1/5/12/` のように、IDを区切り文字で連結する。
この設計により、子孫の取得は `WHERE meta_path LIKE ‘/1/5/%’` という単一のインデックススキャンで完結する。これは計算量を O(N) から O(log M) へと劇的に改善させる。
3. 同期ロジックの設計：フックによる整合性の担保
データベースの整合性は、アプリケーション層ではなく「データの保存ロジック」に埋め込む必要がある。`transition_post_status` フックを利用し、親が変更された際に子孫のパスを再帰的に更新するアトミックなトランザクションを構築せよ。
/
- 投稿保存時にパスを同期するアーキテクチャ
/
add_action(‘transition_post_status’, function($new_status, $old_status, $post) {
global $wpdb;
// 再帰呼び出しを防ぐためのスタティックフラグ
static $updating = false;
if ($updating) return;
$updating = true;
// 新しいパスを計算
$parent_id = $post->post_parent;
$parent_path = ($parent_id > 0)
? $wpdb->get_var($wpdb->prepare(“SELECT meta_path FROM {$wpdb->posts} WHERE ID = %d”, $parent_id))
: ‘/’;
$new_path = $parent_path . $post->ID . ‘/’;
// 自身のパスを更新
$wpdb->update($wpdb->posts, [‘meta_path’ => $new_path], [‘ID’ => $post->ID]);
// 子孫のパスを再帰的に修正（本来は非同期キューが望ましい）
$children = $wpdb->get_col($wpdb->prepare(“SELECT ID FROM {$wpdb->posts} WHERE post_parent = %d”, $post->ID));
foreach ($children as $child_id) {
// ここで子孫のパスを再帰的に再構築するロジックを配置
}
$updating = false;
}, 10, 3);
4. パフォーマンス最適化の極致：メタデータのキャッシュ戦略
MySQL の `LIKE` 検索でさえ、数百万レコード規模ではインデックスの先頭一致とはいえ負荷となる場合がある。ここで重要なのは Object Cache（Redis等）の活用 だ。
1. パス検索のショートカット: `wp_cache_get` を使い、頻繁にアクセスされる階層パスをメモリ上に保持する。
2. クエリキャッシュの汚染防止: `SQL_NO_CACHE` を意図的に使い、頻繁に更新される階層テーブルがクエリキャッシュを埋め尽くさないよう制御する（MySQL 8.0以降では重要度が下がるが、アーキテクチャの基本としては押さえるべき）。
5. 伝説的アーキテクトからの忠告
階層パスの実装は非常に強力だが、一つだけ忘れてはならない。それは「データ不整合の伝搬」だ。
もしロジックのバグやデッドロックでパスが断絶した場合、システム全体が沈黙する。そのため、必ず `wp-cli` で階層パスの整合性を検知・修復するコマンドを用意しておくこと。
実装例：階層パスを強制再構築するコマンド
wp db query “UPDATE wp_posts SET meta_path = NULL; — 整合性修復のためのダンプ・再構築スクリプトを走らせる”
WordPress のコアは美しいが、デフォルトの `wp_posts` は汎用性を追求しすぎた結果、特定のユースケースではボトルネックと化す。このボトルネックを理解し、あえてデータベースの物理構造に手を加える勇気を持つこと。それが、WordPress を単なるCMSから、真のエンタープライズ・アプリケーションへと昇華させる唯一の道である。
真のエンジニアは、フレームワークの制限を言い訳にせず、ランタイムの挙動を支配する。コードを書け。そして、ボトルネックを根絶せよ。