WordPressの心臓部を解剖する：`wp_posts`とInnoDBの「オフページ」という深淵
こんにちは。WordPressのコアを深く掘り下げたいというあなたの好奇心、最高ですね。
多くの開発者は「`wp_posts`テーブルに記事が増えると重くなる」と漠然と理解していますが、その物理的な理由は意外と知られていません。今日は、InnoDBの内部構造、特に`post_content`のような巨大なデータがディスクI/Oをどのように支配しているのか、その「真実」を解説します。
—
1. `wp_posts`の正体とInnoDBの制約
WordPressの`wp_posts`テーブルにある`post_content`カラムは`LONGTEXT`型です。理論上は4GBまで格納できますが、ここで重要なのはMySQL（InnoDB）のデータページサイズです。
InnoDBは通常、データを「16KBのページ」単位で管理します。しかし、一つの行がこの16KBに収まりきらない場合、InnoDBは「オフページ（Off-page）ストレージ」という仕組みを使います。
イメージ図：行の断片化
- インページ（In-page）: ページ内に収まるデータ（ID, post_title, post_dateなど）
- オフページ（Off-page）: ページから溢れた巨大な`post_content`。実際には「ポインタ」だけがページ内に残り、実体は別の領域（溢れページ）に格納されます。
つまり、`post_content`を頻繁に取得するクエリを投げると、MySQLは「メインのページ」だけでなく「溢れた先のページ」までディスクI/Oを発生させることになるのです。これがパフォーマンス低下の物理的な正体です。
—
2. なぜこれがボトルネックになるのか？
開発初学者が陥りがちなのが、「すべてのデータを一つのテーブルに押し込める」という設計です。`post_content`を常に読み出すようなクエリを実行すると、以下の現象が起きます。
1. バッファプールの枯渇: 16KBのキャッシュ枠の中に、長大なテキストデータが居座ることで、他の重要なインデックスデータが追い出されます。
2. ランダムI/Oの増大: 溢れページを読みに行くためにディスクヘッドが動き回り、SSD/HDDのパフォーマンスを食いつぶします。
—
3. 実践：WordPressでどう回避すべきか？
この構造を知った上で、我々開発者が取るべき戦略はシンプルです。「必要なデータだけを読み込む」こと、そして「テーブルの垂直分割」を検討することです。
ダメな例：全てのコンテンツを一度に持ってくる
// 最悪のパターン：wp_postsの全カラムをロード
// post_contentが含まれるため、不必要に大きなI/Oが発生する
$posts = $wpdb->get_results(“SELECT FROM {$wpdb->posts} WHERE post_status = ‘publish'”);
良い例：必要なカラムのみを抽出する
// カラムを絞ることで、InnoDBのページ内に収まりやすくなり
// メモリ効率が劇的に向上します
$posts = $wpdb->get_results(“SELECT ID, post_title, post_date FROM {$wpdb->posts} WHERE post_status = ‘publish'”);
—
4. 上級テクニック：垂直分割の考え方
もし、あなたが独自のカスタム投稿タイプで「極めて巨大なテキストデータを扱う」なら、いっそのこと`post_content`を分離するのも手です。
設計案:
- `wp_posts`: メタデータとタイトル（高速アクセス用）
- `wp_post_contents_extra`: `post_id`と`content_body`（巨大テキスト専用テーブル）
これにより、`wp_posts`テーブルの各行が小さくなり、バッファプールに一度に多くの行がキャッシュされるようになります。
— 巨大なデータだけを別テーブルに逃がす
CREATE TABLE wp_post_contents_extra (
post_id BIGINT(20) UNSIGNED NOT NULL,
content_body LONGTEXT,
PRIMARY KEY (post_id)
) ENGINE=InnoDB;
—
今後のあなたへのアドバイス
WordPressの内部構造を理解することは、単なる「設定」から「アーキテクチャの制御」へとレベルアップすることを意味します。
1. `EXPLAIN`コマンドを友人にしてください: `SELECT`文の前に`EXPLAIN`をつけて、`Extra`カラムに「Using filesort」や「Using temporary」が出ていないか確認しましょう。
2. バッファプールのヒット率を意識: `SHOW ENGINE INNODB STATUS`で、キャッシュがどれくらい効いているか確認する癖をつけてください。
ここをクリアすれば、あなたはもう「WordPressを使っている人」ではなく「WordPressを掌握しているエンジニア」の入り口に立っています。次回の最適化も、この視点で深掘りしていきましょうね。応援していますよ！