wp_postsの物理限界とメモリ内ソート：巨大TEXT型がWordPressクエリを殺す理由
WordPressのパフォーマンスチューニングにおいて、大半の開発者は「クエリキャッシュ」や「オブジェクトキャッシュ（Redis/Memcached）」といったアプリケーション層の最適化に終始する。しかし、数千万レコード規模のエンタープライズ環境や、長年運用されて肥大化したメディアサイトにおいて、システム全体のスループットを決定づけているのは、MySQL（あるいはMariaDB）のストレージエンジン層、すなわちInnoDBの物理メモリ管理と行フォーマットの挙動にほかならない。
本稿では、`wp_posts`テーブルの物理構造、特に`post_content`に代表される`LONGTEXT`/`TEXT`型カラムが、MySQLの内部ソートアルゴリズムとバッファプールに与える影響を低レイヤの視点から解剖し、インデックスのみでクエリを完結させるための極限のアーキテクチャ設計を提示する。
—
1. `wp_posts`の物理レイアウトとInnoDBの行フォーマット
デフォルトのWordPressスキーマにおいて、`wp_posts`はInnoDBストレージエンジンを使用している。InnoDBの「Dynamic」または「Compact」行フォーマットにおいて、可変長カラムや大容量テキストデータはどのように扱われているだろうか。
外部ページ（Off-page storage）と溢れ（Overflow）のメカニズム
InnoDBは、1つのデータページ（デフォルトで16KB）の中にすべての行データを収めようとする。しかし、`post_content`（`LONGTEXT`型、最大4GB）や`post_excerpt`（`TEXT`型）に格納される数キロバイトから数メガバイトの文字列は、B-treeのインデックスレコード内に直接収めることができない。
ここで発生するのがオフページ・ストレージ（Off-page storage）である。
MySQLは、行の本体（クラスタ化インデックスのキーとプレフィックス）を通常のB-treeページに保持しつつ、255バイトを超えるポインタ（外部ページの場所を示す20バイトのローカルプレフィックス＋その他のメタデータ）を介して、実際のテキストデータを「溢れページ（Overflow pages）」に分散して格納する。
この物理挙動が意味するのは以下の点だ：
1. ディスクI/Oの断片化: 記事コンテンツが巨大化するほど、1行を取得するために必要なページ数が非線形に増加する。
2. バッファプールの汚染（Buffer Pool Pollution）: InnoDBはLRU（Least Recently Used）アルゴリズムベースのバッファプールでメモリを管理している。不必要に大きな`post_content`を含む行がスキャンされると、バッファプールの貴重なメモリ領域が肥大化したテキストで瞬時に埋まり、本来キャッシュされるべきインデックスや頻繁にアクセスされるホットデータが追い出される（キャッシュヒット率の急落）。
—
2. `ORDER BY` とメモリ内ソート（Filesort）の内部挙動
次に、WordPressの標準的なループや複雑なWP_Queryが発行された際、MySQLのクエリパーサとオプティマイザの内部で何が起きているのかを追う。
例えば、以下のようなよくあるカスタムクエリを考えてみる。
$args = array(
‘post_type’ => ‘post’,
‘posts_per_page’ => 10,
‘orderby’ => ‘date’,
‘order’ => ‘DESC’,
);
$query = new WP_Query( $args );
インデックスが適切に効いている場合、`wp_posts`の `(post_status, post_date, ID)` あたりの複合インデックスを利用して、オプティマイザはfilesort（ディスクまたはメモリ上でのソート）を回避し、インデックス順にレコードを効率よくフェッチできる。
しかし、もしこれが `meta_value` やカスタムフィールド、あるいは `post_content` を条件にしたソート、あるいはオプティマイザがインデックスを適切に選択できずにFilesortにフォールバックした場合、悲劇が起こる。
現代のMySQLにおける2つのソートアルゴリズム
MySQL（5.6以降）には、Filesortにおいて2つのアルゴリズムが存在する。
1. Modified Filesort (Row IDs): ソート対象のカラムと元の行のポインタ（主キー）のペアのみをソートバッファにロードし、ソート完了後にそのポインタを使って実際のテーブルから行データを再取得する。
2. Original Filesort (Full Row Data): クエリが取得する全カラムのデータ（`post_content`を含む！）をソートバッファに直接ロードし、バッファ内でソートを行う。
`max_length_for_sort_data` の罠
MySQLは、クエリが要求するカラムの合計サイズがシステム変数 `max_length_for_sort_data` を超えると、アルゴリズム1（Row IDs）を選択する。逆にこれ以下であれば、高速だがメモリを大量に消費するアルゴリズム2（Full Row Data）を選択しようとする。
ここで `wp_posts` の真の脅威が現れる。
`SELECT FROM wp_posts …` のように全カラムを取得するクエリ（WordPressのコアや大半のプラグインが内部で発行するクエリのデフォルト挙動）において、もし `post_content` がソート対象や取得対象に含まれ、かつデータサイズがしきい値内と判定された場合、巨大な `post_content` 自体がソートバッファに丸ごとコピーされる。
ソートバッファのサイズは `sort_buffer_size` で制限されている。もしバッファサイズを超過すれば、MySQLは一時ファイル（Temporary Files）をディスク（多くの場合 /tmp または一時表空間）に作成し、マルチマージソートを実行する。
SSDであっても、メモリ上のインメモリソートと比較して数桁のレイテンシ悪化（I/O待ち）を引き起こし、同時接続数（Concurrecy）が増加した瞬間にMySQLのスレッドプールは飽和し、CPU使用率が100%に張り付いたままスレッドがデッドロック寸前の状態に陥る。
—
3. インデックスのみでクエリを完結させる設計指針（Covering Index）
この物理的なボトルネックを完全に回避するための唯一にして最良の解は、「カバリングインデックス（Covering Index）」の概念をWordPressのデータアクセス層に強制することである。
カバリングインデックスとは、クエリが要求するすべてのデータ（WHERE句の条件、ORDER BY、SELECT句で取得するカラム）が、走査するインデックスのツリー構造内にすべて含まれている状態を指す。これにより、InnoDBはデータ本体（クラスタ化インデックス、ひいてはオフページの `post_content`）へのアクセスを完全にバイパスできる。
WordPressにおける実践的実装：フィールドの垂直分割とカスタムテーブル
数百万レコードを超えるスケールにおいて、`wp_posts` の中に全てのメタデータや巨大なコンテンツを同居させる設計自体が、リレーショナルデータベースのアンチパターンである。
シニアエンジニアが採るべきアーキテクチャ戦略は以下の通りだ：
1. `post_content` の分離（Vertical Partitioning）:
コンテンツ本体を別テーブル（例: `wp_post_contents`）に切り出し、`post_id` を主キー/外部キーとする。`wp_posts` 自体の行サイズを極限まで軽量化（数バイト〜数十バイトに抑える）し、InnoDBの1ページあたりにより多くの行を詰め込むことでバッファプールのヒット率を最大化する。
2. クエリの軽量化とフィールド制限（`fields` 引数の活用）:
WordPress標準の `WP_Query` を使う場合でも、不要なデータ転送とメモリアロケーションを防ぐために、取得するフィールドを制限する。
以下は、カスタムテーブルへのデータ分離と、インデックスを完全にヒットさせるための実装パターンのコード例である。
/
- 巨大な wp_posts.post_content の負荷を回避するため、
- コンテンツ本体を別テーブルに分離し、WP_Queryの最適化を行うクラスの例。
/
class Apex_Post_Optimizer {
public function __construct() {
// WP_Query の SQL生成フックに介入し、不要なカラム取得を排除
add_filter( ‘posts_fields’, array( $this, ‘optimize_posts_fields’, 10, 2 );
add_filter( ‘posts_join’, array( $this, ‘optimize_posts_join’, 10, 2 );
}
/
- SELECT 句を軽量化し、wp_posts.post_content のフェッチを抑制する
/
public function optimize_posts_fields( $sql, $query ) {
global $wpdb;
// 特定の軽量クエリでのみ動作させるフラグチェック
if ( ! $query->get( ‘use_covering_index_optimization’ ) ) {
return $sql;
}
// post_content や post_excerpt をSELECTから除外し、必要最小限のメタデータのみ取得
// これによりソートバッファの汚染を防ぎ、インメモリソートを維持する
return “{$wpdb->posts}.ID, {$wpdb->posts}.post_author, {$wpdb->posts}.post_date, {$wpdb->posts}.post_title, {$wpdb->posts}.post_name”;
}
/
- 独自分離テーブルからの結合が必要な場合のJOIN最適化
/
public function optimize_posts_join( $sql, $query ) {
if ( ! $query->get( ‘use_covering_index_optimization’ ) ) {
return $sql;
}
// 例: コンテンツが必要な場合のみ遅延ロード（Lazy Load）するための準備
// 実際のアーキテクチャではここで別テーブルを LEFT JOIN しないことで高速化を維持する
return $sql;
}
}
new Apex_Post_Optimizer();
—
4. データベーススキーマレベルでのアサーション
最後に、MySQLの内部挙動を監視・制御するためのMySQL設定（`my.cnf` / `my.ini`）の指針を明記する。
[mysqld]
InnoDBのバッファプールサイズは物理メモリの70〜80%を割り当てる
innodb_buffer_pool_size = 12G
ソートバッファの過剰な拡大はメモリ枯渇を招くため、ワークロードに応じて適切にチューニング
デフォルト(256KB)から増やす場合は同時接続数とのトレードオフを計算すること
sort_buffer_size = 2M
一時ファイルのディスクI/Oを監視するためのメトリクス確認
SHOW STATUS LIKE ‘Created_tmp_disk_tables’; が急増している場合、
wp_posts のクエリが Filesort を叩いている確実な証拠である。
結論
WordPressのパフォーマンス劣化は、コードの書き方云々よりも、データベースの「物理構造」を無視したクエリ設計に起因することが大半だ。`wp_posts` の `LONGTEXT` 型カラムが持つ物理的特性（オフページストレージとソート時のオーバーヘッド）をエンジニア自身が正確に脳内トレースできなければ、どれほど高価なインフラを投入しようとも、大規模な負荷耐性の壁を突破することはできない。
システム設計の根本からレイヤを剥ぎ取り、データを支配する者だけが、真にスケーラブルなWordPressアーキテクチャを掌握できる。