WordPressの深淵へ：wp_usermetaのEAV構造と「権限チェック」の裏側を掌握する
こんにちは。WordPressのコードベースという迷宮を探索している皆さん。今日は、WordPressのデータベース設計における「影の主役」とも言える`wp_usermeta`テーブルと、それが引き起こすパフォーマンスのボトルネックについて、本質的な話をしましょう。
多くの開発者が何気なく使う`current_user_can()`や`get_userdata()`。これらが裏で何をしているのかを知ることは、WordPressを「ただのブログツール」から「高負荷に耐えうるエンタープライズシステム」へと昇華させるための第一歩です。
—
1. wp_usermetaの正体：EAV構造という「柔軟性」の代償
WordPressのユーザー情報は、`wp_users`（基本情報）と`wp_usermeta`（追加情報）に分かれています。この`wp_usermeta`は、EAV（Entity-Attribute-Value）構造という設計を採用しています。
- Entity（実体）: どのユーザーか (`user_id`)
- Attribute（属性）: どんな情報か (`meta_key`)
- Value（値）: そのデータは何か (`meta_value`)
この構造は非常に柔軟です。「任意の項目を後から追加できる」という強力なメリットがある一方、「特定のユーザーの権限情報を取得するために、数行のレコードをJOINまたはSELECTする必要がある」という物理的な負荷が常に付きまといます。
なぜこれが「権限チェック」のボトルネックになるのか？
`current_user_can()`を呼び出すたびに、WordPressは内部的に`get_userdata()`を実行し、そのユーザーの全メタデータをデータベースから取得しようとします。
もし、ループ処理の中でこの関数を何度も叩いたらどうなるでしょう？
1. 毎回`SELECT FROM wp_usermeta WHERE user_id = X`が走る。
2. 結果セットをPHPの配列に展開する。
3. メタデータのシリアライズを解除（unserialize）する。
このオーバーヘッドは、ユーザー数やメタデータの量が増えるほど指数関数的に重くなります。
—
2. 可視化：負荷を計測する
まずは、自分の環境で「どれくらいクエリが発行されているか」を確認しましょう。`SAVEQUERIES`定数を`wp-config.php`で一時的に有効にすると、`$wpdb->queries`に全SQLが記録されます。
// wp-config.php で定義
define(‘SAVEQUERIES’, true);
// フッターなどで確認
add_action(‘wp_footer’, function() {
global $wpdb;
echo ‘‘;
});
権限チェックを繰り返すと、驚くほど同じクエリが重複して発行されていることに気づくはずです。
—
3. 回避策：キャッシュ戦略による最適化
この負荷を軽減する鉄則は、「一度取得した情報は、メモリ（またはオブジェクトキャッシュ）に閉じ込める」ことです。
悪い例（アンチパターン）
// ループ内で毎回実行すると、その回数分だけDBに問い合わせる
foreach ($users as $user) {
if (user_can($user->ID, ‘edit_posts’)) {
// 処理…
}
}
良い例（キャッシュ活用）
WordPressには、`get_userdata()`を呼び出した際、そのユーザー情報を`WP_User`オブジェクトとしてメモリにキャッシュする機能があります。しかし、さらに踏み込んでメタデータを一括で制御しましょう。
// ユーザーIDを配列で用意して、事前に一括取得する
$user_ids = [1, 2, 3, 4, 5];
// ユーザー情報をキャッシュに乗せる（これだけでクエリは1回に集約される）
cache_users($user_ids);
foreach ($user_ids as $id) {
// get_userdata() はメモリ上のキャッシュを見に行くため、DBクエリは発生しない
$user = get_userdata($id);
if ($user && $user->has_cap(‘edit_posts’)) {
// 処理…
}
}
—
4. 陥りやすい罠：シリアライズと型変換
初心者の方がよくハマるのが、`meta_value`の型変換です。`wp_usermeta`の`meta_value`カラムは`longtext`型であり、すべての値が文字列として保存されます。
- 間違い: `if ($user->meta_value == 1)` と比較する。
- 正解: `if ((int)$user->meta_value === 1)` と明示的にキャストする。
また、配列データを保存する際に`serialize()`されたデータが複雑すぎると、取得時のアンシリアライズ処理がCPU負荷を押し上げます。権限に関連するメタデータは、可能な限りフラットな構造で保存することを心がけてください。
—
最後に：WordPressを掌握するために
「なぜWordPressはこんな非効率な構造をしているのか？」と疑問に思うかもしれません。しかし、このEAV構造こそが、世界中の誰もがプラグインで自由に機能を拡張できる「WordPressの柔軟性」の源泉なのです。
内部構造を知ることは、弱点を知ることです。弱点を知れば、それを回避する設計（キャッシュ戦略やオブジェクト指向でのデータハンドリング）ができるようになります。
ここをクリアしたあなたは、もうただの「WordPressユーザー」ではありません。「WordPressの仕組みを自在に操るエンジニア」です。
次は、Transients APIとRedisを組み合わせた、さらに高度なキャッシュ戦略について語り合いましょうか。何か深掘りしたい部分はありますか？いつでも聞いてくださいね。