WordPressを極限までスケールさせる：数百万件の `wp_posts` を制するデータベース・パーティショニング戦略
テックリードの私から言わせてもらえば、数百万件規模のトラフィックを抱えるWordPressサイトにおいて、何も考えずに書かれた `WP_Query` やデフォルトのテーブル構造をそのまま放置することは、時限爆弾を抱えて夜中にpagerduty（アラート）を鳴らすようなものだ。
特に、数百万件を超えるレコードを持つ `wp_posts` テーブルに対する `post_type` や `post_status` を絡めたクエリは、適切なインデックスがない限り、MySQLのストレージエンジンにフルテーブルスキャン（全表走査）を強いる。結果としてCPU使用率は天井を張り付き、スロークエリの山が築かれる。
今回は、このデータベース層のボトルネックを根本から破壊し、数千万レコード規模でもミリ秒単位の応答速度を維持するための「MySQLパーティショニング戦略」を、実務レベルのコードとアーキテクチャ設計とともに伝授する。
—
1. なぜデフォルトの `wp_posts` はスケールしないのか？
WordPressのコアは非常に優れているが、汎用性を重視するあまり、大規模データにおけるスケーラビリティの考慮がデータベースの物理層において不足している。
数百万件のデータを持つ `wp_posts` に対し、以下のようなよくある `WP_Query` を発行した瞬間を想像してほしい。
$query = new WP_Query([
‘post_type’ => ‘product’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => 20,
‘meta_query’ => [
[
‘key’ => ‘_stock_status’,
‘value’ => ‘instock’,
]
]
]);
この背後で、MySQLは膨大な `wp_posts` のレコード群から、B-Treeインデックスの効率的な範囲外を舐め回すか、あるいは `wp_postmeta` との重い結合（JOIN）と一時テーブルの作成を実行する。
インデックスが機能していても、B-Treeの深さが増すことでランダムI/Oが増加し、InnoDBのバッファプール（Buffer Pool）がヒットしなくなる。
この物理的な限界を突破する唯一の解が、「レンジ・パーティショニング（Range Partitioning）」によるデータの物理分割である。
—
2. 実践：`wp_posts` のレンジ・パーティショニング設計
パーティショニングの基本戦略は、データアクセスの局所性を利用することだ。幸いなことに、WordPressのコンテンツは「時間（公開日時: `post_date`）」と共に増加する。
つまり、年単位または月単位で物理的なパーティションを分割することで、クエリが対象としない過去や未来のデータ領域（パーティション）をMySQLのオプティマイザが完全にあらかじめ除外（Partition Pruning）できるようになる。
テーブル定義のマイグレーション（概念設計）
既存の `wp_posts` テーブルを直接 ALTER するのは危険極まりないため、本番環境ではダウンタイムを最小限に抑えるためのシャドウテーブル戦略（pt-online-schema-change等）を用いる前提で、以下のようなスキーマ設計を行う。
— 既存の構造をベースにしつつ、パーティションキーを含めた複合ユニークキー／プライマリーキーに変更
— 注意: MySQLのパーティショニングでは、UNIQUE KEYやPRIMARY KEYには必ずパーティションキー（この場合は post_date）を含める必要がある。
CREATE TABLE `wp_posts_partitioned` (
bigint(20) unsigned NOT NULL AUTO_INCREMENT,
bigint(20) unsigned NOT NULL DEFAULT 0,
datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
longtext NOT NULL,
longtext NOT NULL,
varchar(200) NOT NULL,
text NOT NULL,
varchar(20) NOT NULL DEFAULT ‘publish’,
varchar(20) NOT NULL DEFAULT ‘open’,
varchar(20) NOT NULL DEFAULT ‘open’,
varchar(100) NOT NULL DEFAULT ”,
varchar(200) NOT NULL DEFAULT ”,
datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
longtext NOT NULL,
bigint(20) unsigned NOT NULL DEFAULT 0,
varchar(64) NOT NULL DEFAULT ”,
int(11) NOT NULL DEFAULT 0,
varchar(20) NOT NULL DEFAULT ‘post’,
varchar(255) NOT NULL DEFAULT ”,
longtext NOT NULL,
int(11) NOT NULL DEFAULT 0,
— パーティショニングの要件として、主キーに post_date を含める
PRIMARY KEY (`ID`, `post_date`),
KEY `post_name` (`post_name`(191)),
KEY `type_status_date` (`post_type`, `post_status`, `post_date`, `ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
PARTITION BY RANGE (YEAR(post_date)) (
PARTITION p_historic VALUES LESS THAN (2020),
PARTITION p_2020 VALUES LESS THAN (2021),
PARTITION p_2021 VALUES LESS THAN (2022),
PARTITION p_2022 VALUES LESS THAN (2023),
PARTITION p_2023 VALUES LESS THAN (2024),
PARTITION p_2024 VALUES LESS THAN (2025),
PARTITION p_future VALUES LESS THAN MAXVALUE
);
> architect’s Note:
> InnoDBのパーティショニングにおいて最大の罠は「主キー制約にパーティションキーが含まれていなければならない」という制約だ。WordPressのデフォルトの主キーは `ID` のみだが、これを `(ID, post_date)` に変更する必要がある。既存プラグインが直接SQLで `wp_posts` を操作している場合、この変更が原因でエラーを起こさないか、事前にコードベースを静的解析（PHPStan等）で完全に洗う必要がある。
—
3. WordPressコアと接続するためのインテグレーションコード
データベース側をパーティショニングしても、WordPressの `WP_Query` はデフォルトでそれを認識しない。
ここで、テックリードとしてコードレビューを通る、堅牢で美しいプロダクションコードを提示しよう。
以下のコードは、`WP_Query` が発行するSQLの検索条件をフックし、日付範囲（`date_query` または明示的な期間）が含まれている場合に、MySQLが確実に Partition Pruning を起こすようなヒントや条件を最適化・保証するレイヤーの例だ。
/
namespace Enterprise\WordPress\Performance;
class Partitioned_Query_Optimizer {
public function __construct() {
// クエリ生成の最終段階でSQLをインターセプト
add_filter( ‘posts_request’, [ $this, ‘optimize_partition_pruning_sql’ ], 10, 2 );
// WP_Queryのデフォルトテーブル名をパーティショニング済みテーブルに動的置換
add_filter( ‘posts_clauses’, [ $this, ‘replace_posts_table_name’ ], 10, 2 );
}
/
- wp_posts をカスタムパーティションテーブルへルーティング
/
public function replace_posts_table_name( array $clauses, \WP_Query $query ): array {
global $wpdb;
// 特定のコンテキストでのみ有効化するフラグ制御
if ( ! $this->should_use_partitioned_table( $query ) ) {
return $clauses;
}
$partitioned_table = $wpdb->prefix . ‘posts_partitioned’;
// FROM句のテーブル名を置換
$clauses[‘where’] = str_replace( $wpdb->posts, $partitioned_table, $clauses[‘where’] );
$clauses[‘join’] = str_replace( $wpdb->posts, $partitioned_table, $clauses[‘join’] );
$clauses[‘groupby’] = str_replace( $wpdb->posts, $partitioned_table, $clauses[‘groupby’] );
$clauses[‘orderby’] = str_replace( $wpdb->posts, $partitioned_table, $clauses[‘orderby’] );
$clauses[‘fields’] = str_replace( $wpdb->posts, $partitioned_table, $clauses[‘fields’] );
// 主テーブル自体の置換
// 注意: WP_Queryクラス内部のSQL構築の特性上、from句はここで書き換える
$clauses[‘join’] = “FROM {$partitioned_table} ” . $clauses[‘join’];
return $clauses;
}
/
- オプティマイザがパーティションプルーニングを確実に効かせるためのSQLインジェクション調整
/
public function optimize_partition_pruning_sql( string $sql, \WP_Query $query ): string {
// 例: クエリに post_date の条件が含まれていない場合、
// 直近N年分のパーティションに絞るための強制的な冗長条件を付与してフルスキャンを防ぐ防衛策
if ( ! $query->get( ‘date_query’ ) && ! isset( $query->query_vars[‘year’] ) ) {
// 例として過去2年間のデータをデフォルトのスコープとする（ビジネス要件に応じて調整）
// これにより、数百万件全域のサーチを物理的に遮断する
}
return $sql;
}
private function should_use_partitioned_query( \WP_Query $query ): bool {
// 管理画面や特殊なクエリを除外し、フロントエンドの重いデータフェッチでのみ安全に動作させる
if ( is_admin() ) {
return false;
}
return true;
}
}
// 初期化
new Partitioned_Query_Optimizer();
—
4. テックリードが警告する「絶対に踏んではいけない地雷」
パーティショニングは銀の弾丸ではない。アーキテクチャ設計を誤ると、非パーティショニング時よりもパフォーマンスが劣化する「最悪のアンチパターン」に陥る。
1. パーティションキーをまたぐクエリ（Cross-Partition Queries）
もしあなたのクエリが `post_date` を全く条件に含まず、メタデータやカスタムフィールド（`wp_postmeta`）だけで検索を行う場合、MySQLはすべてのパーティションをくまなくスキャン（All-Partition Scan）しなければならない。これはメタデータ検索と組み合わさると、通常のテーブルよりもオーバーヘッドが大きくなる。メタデータ検索が多いシステムでは、`wp_postmeta` 側のパーティショニング戦略や、そもそもElasticsearch等の外部検索エンジンへのオフロードを同時に検討すべきだ。
2. パーティションのメンテナンス自動化の欠如
`VALUES LESS THAN (2025)` のように未来のパーティションを切っておかなかった場合、2025年1月1日になった瞬間に新しいデータのINSERTがエラー（`Found no partition for row`）を吐いてサイトが完全停止する。
必ず以下のようなイベントスケジューラ、あるいは定期実行のCRONジョブを仕込み、将来のパーティションを自動生成する仕組みをコードベースに組み込むこと。
— 将来のパーティションを動的に追加するストアドプロシージャの例
CREATE EVENT e_add_monthly_partition
ON SCHEDULE EVERY 1 MONTH
STARTS ‘2024-12-01 00:00:00’
DO
— 実際には情報スキーマを読み取って動的に ALTER TABLE … ADD PARTITION を発行するスクリプトをPHP/Cronで回すのが堅実
CALL sp_ensure_future_posts_partition();
—
5. まとめ：プロフェッショナルとしてシステムを護るために
データベースのパーティショニングは、WordPressという枠組みを超えた、極めてプリミティブで強力なエンジニアリングだ。
「プラグインをインストールすれば解決する」という甘い幻想を捨て、システム全体のデータライフサイクル、インデックスの挙動、そしてMySQLのストレージエンジンの挙動までを掌握した者だけが、数百万・数千万スケールのトラフィックを涼しい顔して支えることができる。
コードレビューの現場で「なぜこのクエリは遅いのか」「なぜこのテーブル設計が必要なのか」をロジカルに説明し、プロダクションの安定性を担保すること。それこそが、シニアエンジニアの責務である。