wp_postsの呪縛を解く：データベース・オフロードによる全文検索の極限最適化
WordPressの `wp_posts.post_content` カラムは、現代のWebアプリケーションにおける「技術的負債の象徴」と言っても過言ではない。MySQLの `LONGTEXT` 型にシリアライズされたHTML断片を詰め込み、`LIKE %keyword%` でワイルドカード検索を投げる。この行為は、データベースエンジンのインデックスを無効化し、フルテーブルスキャンを誘発させ、I/Oバウンドなボトルネックを生成する自殺行為に他ならない。
本稿では、WordPressのコア構造をハックし、物理レイヤーで検索負荷を切り離すためのアーキテクチャ論を解説する。
—
1. なぜ wp_posts での検索は「死」を招くのか
MySQLの `B-Tree` インデックスは、前方一致（`LIKE ‘abc%’`）には機能するが、後方や中間一致（`LIKE ‘%abc%’`）には無力だ。`post_content` に格納されたHTMLソースを検索するということは、ページ単位でヒープ領域をスキャンし、CPUを浪費し、バッファプールを汚染することを意味する。
また、`wp_postmeta` とのJOINを繰り返すクエリは、さらに悲劇を加速させる。クエリプランナーが統計情報を誤読し、最悪の実行計画を選択する可能性は極めて高い。
—
2. アーキテクチャの転換：インデックス・オフロード戦略
物理的な解決策は一つ。「検索対象データを正規化し、分離すること」である。我々は `wp_posts` から全文検索の責任を剥奪し、専用のデータ構造（Elasticsearch またはカスタム・インデックス・テーブル）へオフロードする。
カスタムテーブルによる転換案
もし外部エンジン（Elasticsearch等）の導入が過剰な場合は、`FULLTEXT` インデックスを貼ったカスタムテーブルを作成せよ。
— 推奨されるインデックス用テーブルの定義
CREATE TABLE wp_search_index (
post_id BIGINT(20) UNSIGNED NOT NULL,
search_content LONGTEXT, — HTMLタグを剥ぎ取ったプレーンテキスト
PRIMARY KEY (post_id),
FULLTEXT KEY ft_content (search_content)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
—
3. フックの掌握：更新ライフサイクルの同期
WordPressのコア内部では、`wp_insert_post_data` と `save_post` フックがデータの整合性を司る。我々は、`wp_strip_all_tags()` を用いて正規化したデータを、非同期、あるいはトランザクション内でカスタムテーブルへ同期させる必要がある。
/
- save_postフックを利用したインデックスの更新
- 物理ストレージへの書き込みを最小化するため、非同期処理を推奨するが
- 今回はトランザクション整合性を考慮した同期処理の例を示す。
/
add_action(‘save_post’, ‘sync_search_index_on_post_save’, 20, 3);
function sync_search_index_on_post_save($post_id, $post, $update) {
// リビジョンや自動保存は除外
if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
return;
}
global $wpdb;
// HTMLタグを剥ぎ取り、メモリ上の検索効率を高める
$clean_content = wp_strip_all_tags($post->post_content);
// replace into を使用し、アトミックな更新を保証
$wpdb->replace(
“{$wpdb->prefix}search_index”,
[
‘post_id’ => $post_id,
‘search_content’ => $clean_content
],
[‘%d’, ‘%s’]
);
}
—
4. クエリの再設計：WP_Query を拡張せよ
単純な `WP_Query` ではカスタムテーブルを参照できない。`posts_clauses` フィルターを介入させ、SQLを物理的に書き換える必要がある。
add_filter(‘posts_clauses’, function($clauses, $query) {
global $wpdb;
if ($query->is_search() && !is_admin()) {
$search_term = $query->get(‘s’);
// 既存の LIKE クエリを破棄し、FULLTEXT検索へ差し替える
$clauses[‘join’] .= ” INNER JOIN {$wpdb->prefix}search_index si ON {$wpdb->posts}.ID = si.post_id “;
$clauses[‘where’] = ” AND MATCH(si.search_content) AGAINST(‘” . esc_sql($search_term) . “‘ IN BOOLEAN MODE) “;
// 不要な LIKE 句を削除
$clauses[‘where’] = str_replace(“AND ({$wpdb->posts}.post_title LIKE”, “–“, $clauses[‘where’]);
}
return $clauses;
}, 10, 2);
—
5. 極限の最適化：メモリとキャッシュの戦略
この設計により、検索は `FULLTEXT` インデックスを参照するO(log N)の操作へと進化する。さらにパフォーマンスを極めるならば、以下の3点を意識せよ。
1. MySQLの `innodb_ft_min_token_size` の調整: 日本語環境ではデフォルトのインデックスサイズでは不十分な場合が多い。`my.cnf` で3以下に設定し、単語の網羅性を高める。
2. Object Cacheの活用: 検索結果のクエリIDを `wp_cache_set` で永続化し、データベースヒットをゼロにする。
3. クエリの実行計画監視: `EXPLAIN` コマンドで、常にインデックスが適切に使用されているか（`type: fulltext`）を確認し続けよ。
結びに代えて
WordPressは、使い方次第で「重厚長大なCMS」にも「超高速なコンテンツ検索エンジン」にもなる。大切なのは、wp_postsというブラックボックスにすべてを押し込む怠惰を捨て、データのライフサイクルを物理レベルで制御する姿勢だ。
システムを支配せよ。さもなくば、システムに支配されることになる。