WordPressの深淵：`wp_comments` と `wp_commentmeta` が引き起こすボトルネックの解剖学
WordPressのデータ構造を「単なるブログ用」と見なしているなら、それは大きな誤解だ。`wp_comments` と `wp_commentmeta` の設計は、初期のWebログ時代の名残を色濃く残しており、大規模トラフィック下においてはデータベースの「急所」となり得る。
今日は、コメント数が数百万件規模に達した際に発生する、I/O負荷とクエリ遅延の正体を、カーネルレベルに近い視点で解剖する。
—
1. 物理構造の脆弱性：EAVモデルの代償
`wp_commentmeta` は、典型的な EAV（Entity-Attribute-Value）モデル で実装されている。
- `meta_key`: インデックスのカーディナリティ（値の多様性）が低い。
- `meta_value`: `LONGTEXT` 型として定義されており、インデックスを貼ってもプレフィックス長に制限がかかる。
大規模サイトで `get_comment_meta()` が多用されると、MySQLのバッファプールはメタデータ検索のためのランダムアクセスで埋め尽くされる。特に、`comment_id` に対して複数のメタデータが紐付く場合、InnoDBのクラスタ化インデックス（主キーによる物理的並び替え）を外れた検索が発生し、ディスクI/Oが激増する。
—
2. クエリ負荷の真犯人：コメント階層（Nested Setsの欠如）
WordPressのコメントは、`comment_parent` による自己参照型の隣接リスト（Adjacency List）で管理されている。この構造の致命的な欠陥は、「階層の再帰的取得」にある。
`get_comments()` を叩いた際、WordPressは単一のフラットなクエリで全データを取得し、PHP側でメモリを展開して階層化する。これが数万件のコメントを抱える記事で発生すれば、以下の現象が連鎖する。
1. メモリ枯渇: PHPの `WP_Comment` オブジェクトの配列がヒープ領域を圧迫。
2. CPUスパイク: `wp_filter_comment_list` などのフックが大量のオブジェクトに対して走る。
3. ロック競合: `wp_comments` への書き込みと読み込みが混在し、InnoDBの行ロックが長時間保持される。
—
3. 最適化の極致：インデックス戦略とキャッシュレイヤ
このボトルネックを解消するには、標準のクエリに頼らず、データベースの物理構造をハックする必要がある。
A. 複合インデックスによるカバリングインデックスの実現
デフォルトでは `comment_post_ID` にしかインデックスがないケースが多い。特定のクエリパターン（例：ステータス別、投稿別）に合わせて、複合インデックスを明示的に張る。
— 投稿IDとステータス、日付を組み合わせた複合インデックス
— これにより、filesortを回避し、インデックススキャンのみでクエリを完結させる
CREATE INDEX idx_post_status_date ON wp_comments (comment_post_ID, comment_approved, comment_date_gmt);
B. `commentmeta` のデノーマライズ（非正規化）
頻繁に検索対象となるメタデータがあるなら、`wp_comments` テーブルに直接カラムを追加せよ。EAVモデルを脱却し、リレーショナルな正規化テーブルへ移行することで、JOINコストをゼロにできる。
C. オブジェクトキャッシュの「プリフェッチ」
WordPressの標準的な `get_comments` は、実行時に必要に応じてメタデータをロードする（N+1問題の温床）。これを防ぐには、WP_Comment_Query の `update_comment_meta_cache` を活用し、あらかじめメモリ上に展開する。
// シニアエンジニアの嗜み：必要なメタデータだけを事前にキャッシュへ載せる
add_filter(‘comments_clauses’, function($clauses, $wp_comment_query) {
// クエリ実行時にメタデータを一括キャッシュ（prefetching）させる
$wp_comment_query->query_vars[‘update_comment_meta_cache’] = true;
return $clauses;
}, 10, 2);
—
4. 伝説のアーキテクトからの提言
システムが限界に達したとき、解決策は「プラグインの設定」には存在しない。
1. クエリの分離: 読み取り専用のリードレプリカを構築し、`wp_comments` への検索負荷をプライマリから隔離せよ。
2. 非同期化: コメントの階層計算やカウントアップは、Webサーバーのレスポンスパスから切り離し、Redis上のカウンターへオフロードせよ。
3. データパージ: `wp_commentmeta` の古いレコードをアーカイブログとして別のストレージに逃がし、ライブテーブルのサイズを常にバッファプールに収まるサイズに維持せよ。
WordPressは、使い方次第でエンタープライズ級の負荷に耐えうる。その鍵は、データベースの挙動を「ブラックボックス」として扱うのをやめ、InnoDBのページ構造や実行計画（`EXPLAIN`）を完全に掌握することにある。
技術は裏切らない。ただ、設計の怠慢を許さないだけだ。