WordPressの暗部：`wp_posts`のTEXT型とInnoDBオフページストレージが引き起こすI/O地獄
WordPressのパフォーマンスを語る際、多くのエンジニアは「キャッシュプラグインを入れる」という表層的な対処に終始する。だが、本質的なボトルネックは常にデータベースの物理層に潜んでいる。
今回は、`wp_posts`テーブルにおける`post_content`という「巨大な爆弾」が、MySQL（InnoDB）のバッファプールとディスクI/Oにどのような物理的負荷を与えているのかを深掘りする。
—
1. InnoDBのページ構造と「オフページストレージ」の罠
InnoDBはデータを「ページ（デフォルト16KB）」単位で管理する。問題は、`post_content`（LONGTEXT型）が格納される際、そのデータ長が16KBを超えると発生する「オフページストレージ（Off-page storage）」だ。
- インラインストレージ: ページ内にデータが収まる場合、高速なメモリ（バッファプール）上で完結する。
- オフページストレージ: ページ内に収まらない場合、InnoDBは「BLOBオーバーフローページ」を別途確保し、そこに実データを書き込む。メインページにはその参照先ポインタだけが残る。
ここが重要だ：
`SELECT FROM wp_posts` を実行した瞬間、MySQLはインラインのメタデータだけでなく、わざわざディスク上の別領域へポインタを辿ってBLOBページをフェッチしに行く。この「ポインタ・チェイシング」こそが、高負荷時にCPUとディスクI/Oを食いつぶす真犯人である。
—
2. 実務で採用すべき「垂直分割」アーキテクチャ
`wp_posts`を肥大化させないための鉄則は、「コンテンツ本体とメタ情報の分離」だ。
長大な記事データ、あるいはJSON形式の外部APIレスポンスを`post_content`に突っ込むのは、データベース設計のアンチパターンである。
もしあなたが大規模なカスタム投稿を設計しているなら、以下のように独自のデータストアを切り出すべきだ。
実装例：カスタムデータテーブルへのオフロードと連携
`wp_posts`は「インデックスと構造」のみを管理し、巨大な実データは別テーブルの`TEXT`カラムで保持する。これにより、一覧取得時のI/O負荷を劇的に削減できる。
/
- カスタムデータテーブルからコンテンツをフェッチする堅牢なラッパー
- wp_postsの肥大化を防ぎ、必要時のみ別テーブルからフェッチする設計
/
class ContentRepository {
public static function get_large_content(int $post_id): string {
global $wpdb;
$table_name = $wpdb->prefix . ‘large_content_store’;
// キャッシュ戦略：内部WP_Object_Cacheを利用してクエリ自体を抑制
$cache_key = “large_content_{$post_id}”;
$content = wp_cache_get($cache_key, ‘custom_repo’);
if (false === $content) {
// カラムを絞り込み、不要なI/Oを回避する
$content = $wpdb->get_var($wpdb->prepare(
“SELECT content_body FROM {$table_name} WHERE post_id = %d LIMIT 1″,
$post_id
));
wp_cache_set($cache_key, $content, ‘custom_repo’, HOUR_IN_SECONDS);
}
return $content ?: ”;
}
}
—
3. なぜ `wp_postmeta` ではなく「独自テーブル」なのか
「`wp_postmeta`を使えばいいのでは？」という声が聞こえるが、それは大きな間違いだ。
`wp_postmeta`は`meta_key`と`meta_value`のペアで構成されるEAV（Entity-Attribute-Value）モデルであり、インデックス効率が極めて悪い。
- 検索性: `wp_postmeta`でJOINを繰り返すと、クエリプランナーが最適解を見失う。
- 物理サイズ: `meta_value`は`LONGTEXT`型であり、ここも当然オフページストレージの対象となる。
結論: 大規模なデータセットを扱うなら、必ず専用のテーブルを定義し、プライマリキーで1:1のリレーションを持たせること。これが、InnoDBのバッファプール効率を最大化する唯一の道だ。
—
4. パフォーマンスを掌握するためのチェックリスト
1. `post_content`の長さを監視せよ:
`SELECT AVG(LENGTH(post_content)) FROM wp_posts;` を実行し、平均値が8KBを超えていないか確認せよ。
2. `SELECT ` を禁止せよ:
コードレビューにおいて`get_posts`で`post_content`が不要な場合、必ず`fields => ‘ids’`や、`no_found_rows => true`を活用してクエリを削ぎ落とせ。
3. InnoDB Buffer Pool Size:
MySQL設定において、バッファプールはメモリの70-80%を割り当てるのが基本だが、オフページストレージが多用されている環境では、メモリをいくら積んでもI/O待ちが発生する。物理設計の見直しが先決である。
—
最後に
WordPressは「誰でも使える」システムとして設計されているが、内部構造は非常に奥が深い。`wp_posts`のテーブル設計をそのまま信じて思考停止する開発者と、DBの物理層まで見通して設計を制御できるエンジニア。この差が、ユーザーが体感する「一瞬の表示速度」に直結する。
システムが巨大化するほど、コードの美しさよりも「データの配置」が正解を決める。さあ、今すぐあなたのデータベーススキーマを再点検してほしい。