wp_postsの呪縛を断つ：再帰的JOINを排除し、極限スケールで階層構造を解決するデータベース戦略
WordPressのデータベーススキーマ、特に `wp_posts` テーブルとそのメタデータ構造は、Web黎明期の設計思想を色濃く残している。`post_parent` カラムを用いた自己参照（Self-Referencing）による階層構造の表現は、小規模なデータセットにおいては直感的で優美に見える。
しかし、数百万件規模のレコードを持つエンタープライズ環境において、この設計はシステム全体を崩壊させる時限爆弾へと変貌する。
本稿では、階層構造を持つカスタム投稿タイプやページ群において、RDB（MySQL/MariaDB）のボトルネックとなる「再帰的JOIN」や「複雑な子孫探索クエリ」を完全に排除し、フラットかつO(1)の計算量に近い極限のパフォーマンスで親子関係を解決する実践的アーキテクチャを解剖する。
—
1. なぜ `post_parent` の再帰的探索はスケールしないのか
開発者が陥る最初の罠は、特定の投稿の「すべての祖先（Ancestors）」あるいは「すべての直系の子孫（Descendants）」を動的に取得しようとすることだ。
愚直な実装では、以下のようなループ、あるいはSQLでの再帰的CTE（Common Table Expressions）が使用される。
— MySQL 8.0以降における再帰的CTEによる子孫取得の例（アンチパターン）
WITH RECURSIVE descendant_posts AS (
SELECT ID, post_parent, post_title
FROM wp_posts
WHERE ID = %d — 起点となる投稿ID
UNION ALL
SELECT p.ID, p.post_parent, p.post_title
FROM wp_posts p
INNER JOIN descendant_posts dp ON p.post_parent = dp.ID
)
SELECT FROM descendant_posts;
このクエリが大規模サイトで致命的なパフォーマンス劣化を引き起こす理由は明白である。
1. インデックスの不効率な走査: `post_parent` にインデックスが存在していても、ツリーの深さ（Depth）に比例して一時表（Temporary Table）の生成と結合が繰り返し発生する。
2. InnoDBバッファプールの汚染: ランダムなI/Oを引き起こし、メモリ上のホットデータがキャッシュアウトする。
3. PHPメモリ枯渇の誘発: 取得した膨大なID配列を `get_posts()` や `WP_Query` に渡し、さらに各投稿の `wp_postmeta` をキャッシュなしでN+1クエリ的にロードする惨劇が生まれる。
WordPressコア自体、`get_page_children()` や階層関連のクエリにおいて、DB側での再帰処理を避けて全件に近いデータをメモリ上にロードし、PHP側でツリーを構築するという強硬手段をとってきた歴史がある。これもまた、データ量が増大すればメモリ限界（OOM Error）を引き起こす悪夢である。
—
2. 解決策：クロージャーテーブル（Closure Table）パターンとパス列挙の併用
この限界を突破するためには、関係性のデータを `wp_posts` から完全に分離し、リレーショナルデータベースの特性に最適化された物理構造を別途定義する必要がある。
我々が採用すべきは、階層関係を別テーブルで管理するクロージャーテーブル（Closure Table）、あるいは検索の深さを限定したパス列挙（Path Enumeration）のハイブリッド戦略だ。
データベーススキーマの拡張
WordPressのマイグレーションAPI（`dbDelta`）を用い、専用の相関テーブルを生成する。
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
$charset_collate = $wpdb->get_charset_collate();
$sql = “CREATE TABLE {$table_name} (
ancestor BIGINT(20) UNSIGNED NOT NULL,
descendant BIGINT(20) UNSIGNED NOT NULL,
depth INT(11) UNSIGNED NOT NULL DEFAULT 0,
PRIMARY KEY (ancestor, descendant),
KEY descendant (descendant),
KEY depth (depth)
) {$charset_collate};”;
require_once( ABSPATH . ‘wp-admin/includes/upgrade.php’ );
dbDelta( $sql );
このテーブルの思想は極めてシンプルである。
「自分自身」を含むすべての親子関係のペアをレコードとして保持する。
- `ancestor`: 祖先（または親、あるいは自分自身）の投稿ID
- `descendant`: 子孫（または子、あるいは自分自身）の投稿ID
- `ancestor` から `descendant` に至るまでの階層の深さ (`depth`)
例えば、`ID: 10` の投稿の下に `ID: 20` があり、その下に `ID: 30` がある場合、テーブルには以下のレコードが物理的に存在することになる。
| ancestor | descendant | depth |
| :— | :— | :— |
| 10 | 10 | 0 |
| 20 | 20 | 0 |
| 30 | 30 | 0 |
| 10 | 20 | 1 |
| 20 | 30 | 1 |
| 10 | 30 | 2 |
この構造により、「ID: 10 のすべての子孫を瞬時に取得する」クエリは、再帰を完全に排除した単なる一回の `JOIN` または `WHERE` 句に還元される。
SELECT p.
FROM wp_posts p
INNER JOIN wp_post_closure c ON p.ID = c.descendant
WHERE c.ancestor = 10
AND c.depth > 0
AND p.post_status = ‘publish’;
このクエリは `ancestor` に貼られたプライマリキーまたはインデックスをダイレクトにヒットさせるため、データ量が100万件を超えようとも、実行計画は常に `O(1)` に近い極小のコスト（Const / Ref）を維持する。
—
3. WordPressライフサイクルへのフックと非同期メンテナンス
このクロージャーテーブルを実運用に組み込むためには、WordPressの投稿保存・更新・削除のライフサイクル（`save_post`, `delete_post`）に正確にフックし、グラフ構造を同期させる必要がある。
以下に、コアの整合性を担保しながら、トランザクション安全性を考慮した堅牢なハンドラーの実装を示す。
class WP_Advanced_Hierarchy_Manager {
public static function init() {
add_action( ‘save_post’, [ __CLASS__, ‘handle_save_post’ ], 10, 3 );
add_action( ‘before_delete_post’, [ __CLASS__, ‘handle_delete_post’ ], 10, 1 );
}
/
- 投稿保存時のクロージャーテーブル再構築
/
public static function handle_save_post( $post_id, $post, $update ) {
// リビジョンやオートセーブ、ゴミ箱移動時などは除外
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
if ( ‘publish’ !== $post->post_status && ‘private’ !== $post->post_status ) {
// 必要に応じてステータスの条件は調整
// ここでは簡易的に全ステータスを対象とする
}
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
// トランザクション開始
$wpdb->query( ‘START TRANSACTION’ );
try {
// 1. 既存のこのノードに関する関連性を一旦削除（サブツリー移動に対応するため）
// ※厳密には影響範囲のみを更新すべきだが、安全性のため該当ノードを起点とするパスを再計算する
$wpdb->query( $wpdb->prepare( “DELETE FROM {$table_name} WHERE descendant = %d AND ancestor != %d”, $post_id, $post_id ) );
// 2. 自己参照（Self）レコードの保証
$wpdb->query( $wpdb->prepare(
“INSERT INTO {$table_name} (ancestor, descendant, depth) VALUES (%d, %d, 0)
ON DUPLICATE KEY UPDATE depth = 0”,
$post_id, $post_id
) );
// 3. 親が存在する場合、親のすべての祖先を自分の祖先として結合する
$parent_id = $post->post_parent;
if ( $parent_id > 0 ) {
$sql = $wpdb->prepare(
“INSERT INTO {$table_name} (ancestor, descendant, depth)
SELECT ancestor, %d, depth + 1
FROM {$table_name}
WHERE descendant = %d
ON DUPLICATE KEY UPDATE depth = VALUES(depth)”,
$post_id,
$parent_id
);
$wpdb->query( $sql );
}
// 4. もしこの投稿が子を持っている場合、この投稿の新しい祖先関係を全ての子孫に伝播させる
// （高度なグラフ操作。必要に応じてキューイング処理に逃がすべき）
self::propagate_descendants( $post_id );
$wpdb->query( ‘COMMIT’ );
} catch ( Exception $e ) {
$wpdb->query( ‘ROLLBACK’ );
error_log( ‘Hierarchy Sync Error: ‘ . $e->getMessage() );
}
}
private static function propagate_descendants( $ancestor_id ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
// 簡易的な伝播ロジックのプレースホルダー
// 大規模なツリーの移動時は、ここをAction Scheduler等による非同期処理にオフロードする
}
public static function handle_delete_post( $post_id ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
// 関連するパスを物理削除
$wpdb->query( $wpdb->prepare( “DELETE FROM {$table_name} WHERE ancestor = %d OR descendant = %d”, $post_id, $post_id ) );
}
}
WP_Advanced_Hierarchy_Manager::init();
—
4. パフォーマンスの極限最適化：オブジェクトキャッシュとの統合
データベース層でのO(1)解決を手に入れたとしても、高トラフィック環境においては、毎リクエストごとのSQL発行すら排除すべきである。
ここで、WordPressの `WP_Object_Cache`（Redis / Memcachedバックエンド）を最大限に活用したキャッシュ戦略を組み込む。
class WP_Cached_Hierarchy_Resolver {
/
- 指定投稿のすべての祖先ID配列をO(1)かつキャッシュヒットで取得
/
public static function get_ancestor_ids( $post_id ) {
$cache_key = ‘post_ancestors_’ . $post_id;
$ancestors = wp_cache_get( $cache_key, ‘hierarchy_optimization’ );
if ( false === $ancestors ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
$ancestors = $wpdb->get_col( $wpdb->prepare(
“SELECT ancestor FROM {$table_name} WHERE descendant = %d AND depth > 0 ORDER BY depth ASC”,
$post_id
) );
// 永続キャッシュに保存（タグベースの無効化が望ましい）
wp_cache_set( $cache_key, $ancestors, ‘hierarchy_optimization’, HOUR_IN_SECONDS );
}
return $ancestors;
}
/
- 指定投稿の直系の子（Children）ID配列を取得
/
public static function get_child_ids( $post_id ) {
$cache_key = ‘post_children_’ . $post_id;
$children = wp_cache_get( $cache_key, ‘hierarchy_optimization’ );
if ( false === $children ) {
global $wpdb;
$table_name = $wpdb->prefix . ‘post_closure’;
// depth = 1 のみが直系の子
$children = $wpdb->get_col( $wpdb->prepare(
“SELECT descendant FROM {$table_name} WHERE ancestor = %d AND depth = 1”,
$post_id
) );
wp_cache_set( $cache_key, $children, ‘hierarchy_optimization’, HOUR_IN_SECONDS );
}
return $children;
}
}
投稿の保存・更新時には、対応するキャッシュキーを確実にパージ（`wp_cache_delete`）するフックを仕込んでおくことで、データベースサーバーのCPU使用率を極限まで低く抑え込むことが可能になる。
—
5. 結び：WordPressを「真のスケールするCMS」へ昇華させるために
WordPressは、そのアクセシビリティの高さゆえに「おもちゃのCMS」と揶揄されることがある。しかし、内部コアのデータベース構造の限界を正しく理解し、リレーショナルデータベース理論に基づいた適切な拡張（今回解説したクロージャーテーブル等）を施すことで、金融系や大規模メディアプラットフォームの基盤としても十分に耐えうる堅牢なシステムへと進化させることができる。
`wp_posts` の制約に縛られる時代は終わった。
データベースの物理レイヤを掌握し、クエリの実行計画を完全にコントロールすること。それこそが、シニアエンジニアに求められる真のWordPress制覇のあり方である。