大規模WordPressの限界突破：数千万件の `wp_posts` に対する水平分割（シャーディング）とクエリ最適化の極意
WordPressは、その直感的なアーキテクチャと低い参入障壁ゆえに、本来の想定設計規模を遥かに超えたエンタープライズ環境へと投入されることが多い。数千万件から数億件オーダーのレコードを抱える `wp_posts` テーブル、そしてそれと密結合する `wp_postmeta`。この状態のデータベースに対し、素朴な `WP_Query` を投げることがいかにシステム全体への暴力であるか、シニアエンジニアであれば説明不要だろう。
テーブルロック、B-Treeインデックスの肥大化によるキャッシュヒット率の低下、そしてMySQLのクエリプランナが誤った実行計画を選択した瞬間に発生するフルテーブルスキャン（O(N)の絶望）。これらを解決するためには、アプリケーション層の小手先のキャッシュ（RedisやMemcached）だけでは不十分であり、ストレージ層およびクエリパーサの挙動を熟知したデータベースの水平分割（シャーディング）が不可欠となる。
本稿では、WordPressのコアロジックを破壊することなく、数千万件の `wp_posts` をマルチデータベースへ安全にシャーディングし、`WP_Query` の寿命を極限まで引き延ばすためのアーキテクチャと実装コードを提示する。
—
1. `wp_posts` シャーディングにおける根本的課題
データベースのシャーディングにおける最大の難所は、単一のSQL文でのJOINやトランザクションの保証が失われることだ。特にWordPressは、`posts` と `postmeta`、`term_relationships` が密接にリレーションを組んでおり、通常のRDBMSの振る舞いを前提としている。
WordPressコアにおける結合の呪縛
`WP_Query` の内部挙動を追うと、`WP_Tax_Query` や `WP_Meta_Query` が生成するSQLは、以下のような複合的なJOINとサブクエリを多用する。
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
WHERE wp_posts.post_type = ‘post’
AND wp_postmeta.meta_key = ‘target_key’
AND wp_postmeta.meta_value = ‘target_value’
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10;
このクエリに対して、単純に `wp_posts` をシャードA, シャードBへと垂直・水平分割すると、JOIN先である `wp_postmeta` との物理的なデータlocality（局所性）が失われ、クロスシャード結合（Distributed JOIN）によるネットワークI/Oのボトルネックが爆発的に発生する。
したがって、シャーディングの戦略としては以下の2択に絞られる。
1. 結合単位での同居（Co-sharding）: `wp_posts` の特定IDのレコードと、対応する `wp_postmeta` のレコードを、同一の物理シャード内に強制配置する。
2. クエリの完全分離とアプリケーション層でのマージ: `WP_Query` のSQL生成プロセス（`posts_request` フック等）をフックし、適切なシャードへクエリをルーティングする。
—
2. アーキテクチャ設計：レンジベース・シャーディングとルーティング層
数千万件のデータを扱う場合、ハッシュベース（ID % シャード数）のシャーディングは、データの追加や将来的なスケールアウト（リシャーディング）のコストが高すぎる。そのため、時系列あるいはテナントIDに基づいた レンジベース・シャーディング を採用するのが現実的である。
ここでは、`post_date` の年単位、もしくは `ID` の範囲（例: 1000万件ごと）によってシャードをルーティングするカスタムデータベースドライバの概念を構築する。
データベース接続の動的切替メカニズム
WordPressはデフォルトで単一の `$wpdb` インスタンスをグローバルに保持する。これを拡張し、クエリに含まれる条件（`post_id` や `post_date`）をパースして、接続先データベースハンドルを動的に切り替えるプロキシ層を実装する。
class Sharded_WPDB extends wpdb {
private $shards = [];
public function __construct( $user, $password, $name, $host ) {
parent::__construct( $user, $password, $name, $host );
// シャード接続の初期化
$this->shards = [
‘shard_1’ => new mysqli(‘host_1’, ‘user’, ‘pass’, ‘wp_shard_1’),
‘shard_2’ => new mysqli(‘host_2’, ‘user’, ‘pass’, ‘wp_shard_2’),
];
}
/
- クエリを解析し、適切なシャードへルーティングする
/
public function query( $query ) {
$target_shard = $this->determine_shard( $query );
if ( $target_shard ) {
return $target_shard->query( $query );
}
return parent::query( $query );
}
private function determine_shard( $query ) {
// 例: WHERE ID = X または wp_posts.ID IN (…) の解析
if ( preg_match( ‘/ID\s=\s([0-9]+)/i’, $query, $matches ) ) {
$post_id = (int) $matches[1];
return $this->get_shard_by_post_id( $post_id );
}
// グローバルクエリ（全シャード集約が必要な場合）のハンドリング
return null;
}
private function get_shard_by_post_id( $post_id ) {
// レンジベースのルーティングロジック
if ( $post_id < 10000000 ) {
return $this->shards[‘shard_1’];
}
return $this->shards[‘shard_2’];
}
}
—
3. `WP_Query` の最適化とインデックスチューニング
シャーディングを行ってもなお、インデックス設計が甘ければデータベースは悲鳴を上げる。MySQLのB-Treeインデックスの特性を理解し、`wp_posts` および `wp_postmeta` に適切な複合インデックスを張る必要がある。
1. `wp_posts` の複合インデックス
WordPressのデフォルトのインデックス（`type_status_date` 等）は優れているが、カスタムクエリが多発する大規模環境では、以下の複合インデックスを追加で定義し、エクストラなソート（Using filesort）を完全に排除する。
— post_type と post_status、そして頻繁にソートに使われる post_date の組み合わせ
ALTER TABLE wp_posts ADD INDEX idx_type_status_date_id (post_type, post_status, post_date, ID);
2. `wp_postmeta` の EAV（Entity-Attribute-Value）問題への特効薬
`wp_postmeta` は最悪のアンチパターンであるEAVモデルを採用しているため、メタデータを複数条件で絞り込むクエリは一瞬でスロースクエリとなる。
これを回避するため、頻繁に検索条件として使われる `meta_key` と `meta_value` に対して、プレフィックス長を指定したインデックスを構築する。
— meta_key のカーディナリティが低い場合でも効率的にヒットさせる
ALTER TABLE wp_postmeta ADD INDEX idx_key_val_post (meta_key(32), meta_value(191), post_id);
※ `meta_value` は `LONGTEXT` 型であるため、そのままではインデックスを張れない。必ずプレフィックスインデックス（例: `(191)`）を指定し、InnoDBのキー長制限（767バイト〜3072バイト）を回避すること。
—
4. ページネーションの限界突破：`SQL_CALC_FOUND_ROWS` の排除
大規模サイトにおける最大のパフォーマンス殺人鬼は、`WP_Query` がデフォルトで発行する `SQL_CALC_FOUND_ROWS` である。
SELECT SQL_CALC_FOUND_ROWS wp_posts. FROM wp_posts … LIMIT 0, 10;
SELECT FOUND_ROWS();
この `SQL_CALC_FOUND_ROWS` は、MySQLに対して「LIMIT句を無視して条件に一致するすべての行をスキャンしろ」と命令するものであり、数千万件のテーブルにおいてクエリの実行時間を数秒から数十秒へと跳ね上げる。
完全な対策：総件数計算の排除（無限スクロールまたはカーソルベースの採用）
コードレベルでこれを無効化し、さらに `no_found_rows => true` を強制するフィルタを記述する。
/
- すべての WP_Query から SQL_CALC_FOUND_ROWS を強制排除し、
- ページネーションの総件数クエリを殺害する。
/
add_action( ‘pre_get_query’, function( $query ) {
if ( ! is_admin() ) {
// 総件数計算を無効化
$query->set( ‘no_found_rows’, true );
}
});
/
- 念のため、生成されるSQL自体から SQL_CALC_FOUND_ROWS キーワードを除去
/
add_filter( ‘query’, function( $sql ) {
if ( strpos( $sql, ‘SQL_CALC_FOUND_ROWS’ ) !== false {
$sql = str_replace( ‘SQL_CALC_FOUND_ROWS’, ”, $sql );
}
return $sql;
});
総件数が分からない場合、UI/UX側では「総ページ数（例: 1 / 50000ページ）」の表示を諦め、「次へ / 前へ」あるいは無限スクロール（カーソルベース・ページネーション：`ID < last_seen_id`）に移行する。これにより、クエリのコストを常に `O(LIMIT)` に収めることが可能となる。 /
- カーソルベース（シークメソッド）による超高速なWP_Queryの構築例
/
function get_optimized_posts( $last_id = 0, $limit = 20 ) {
global $wpdb;
// LIMIT句を使ったオフセット（OFFSET N）は数千万件では死亡する。
// 常に直前のIDをキーにしたカーソル（WHERE ID < $last_id）を使用する。
$safe_last_id = absint( $last_id );
$safe_limit = absint( $limit );
$sql = $wpdb->prepare(
“SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_type = ‘post’
AND post_status = ‘publish’
AND ID < %d
ORDER BY ID DESC
LIMIT %d",
$safe_last_id,
$safe_limit
);
return $wpdb->get_results( $sql );
}
—
5. まとめ
数千万件の `wp_posts` を抱えるWordPressシステムにおいて、データベースのシャーディングとクエリの最適化は、もはや「オプション」ではなく「生存のための必須条件」である。
1. `SQL_CALC_FOUND_ROWS` の完全排除 と カーソルベース・ページネーション への移行により、スキャン行数を定数オーダーに抑える。
2. EAV構造の弱点を補うプレフィックス・コンポジットインデックス の徹底。
3. アプリケーション層（`wpdb` の拡張）での 動的シャードルーティング によるスケールアウト性の確保。
これらを体系的に実装し、データベースの物理的な挙動とメモリレイヤの限界をコントロール下に置くことこそが、真のエンタープライズWordPressアーキテクトの仕事である。限界など存在しない。あるのは不適切な設計だけだ。