Cloud Spannerクエリプランキャッシュの深層：コンパイルの呪縛を断ち切り、レイテンシを極限まで削ぎ落とす技術
テックリードの私だ。コードレビューや設計レビューの場において、Cloud Spannerを使いこなせているかと問えば、多くのエンジニアは「スキーマ設計」や「スプリット管理」について語り始める。しかし、それだけでは二流だ。
極限のスケールと予測可能な低レイテンシ（p99 < 10ms）が求められるシステムにおいて、真の差を生むのは「クエリの実行プランがどのように生成され、キャッシュされ、そして消費されているか」の深い理解である。
今回は、Spannerの頭脳とも言える「クエリプランキャッシュ（Query Plan Cache）」のメカニズムを解剖し、実務の現場で絶対に踏んではならない地雷と、スループットを限界突破させるための設計パターンを授けよう。
—
1. クエリプランキャッシュの「内部生態系」を理解する
まず大前提として、Cloud Spannerに送られたSQL文字列は、そのまま実行されるわけではない。
リレーショナルデータベースの常として、SQLは以下のライフサイクルを辿る。
1. パース（Parsing）: 構文解析
2. バインド（Binding）: スキーマやテーブル名の解決
3. オプティマイザ（Optimizer）: 統計情報に基づいた最適な実行プラン（物理演算グラフ）の導出
4. コンパイル（Compilation）: 実行可能なバイトコードへの変換
5. 実行（Execution）: 分散ストレージ層（Split）へのスキャンリクエスト発行
この中の 3 と 4（オプティマイザとコンパイル） は、CPUバウンドであり、かつ数十〜数百ミリ秒のオーダーを消費する「重い処理」だ。
もし、高頻度で実行されるOLTPクエリのたびにこれをやっていたらどうなるか？ CPUはクエリの実行ではなく、プランの組立に浪費され、スルーパットは地に落ちる。ここで登場するのが「クエリプランキャッシュ」だ。
キャッシュのキーとスコープ
Spannerのプランキャッシュは、「正規化されたクエリ文字列」と「環境（セッション・統計情報）」をキーとして、各ノードのメモリ上に保持される。
重要なのは、これがセッション単位（あるいはその背後のノード）で管理されている点だ。そのため、コネクションプール層（アプリケーションサーバー側）の設計が拙いと、キャッシュのヒット率が劇的に低下する。これについては後述する。
—
2. なぜあなたのクエリは「キャッシュミス」を連発するのか？（無効化の罠）
現場でよくあるアンチパターンがこれだ。
「動的SQL」や「文字列結合」を使い、アプリケーション側でSQLを組み立てているケース。これをやると、Spannerのプランキャッシュは一瞬でゴミ溜めと化す。
典型的なアンチパターン：リテラルの埋め込み
— ❌ 絶対にやってはいけない：IDを直接SQLに埋め込む
SELECT user_id, name, updated_at
FROM Users
WHERE status = ‘ACTIVE’ AND age > 28;
このアプローチでは、年齢(`28`)が変わるたびに、Spannerからは「全く異なる新しいSQL文字列」に見える。結果として、クエリプランキャッシュはヒットせず、毎回オプティマイザが起動してCPUを焼き尽くす。さらに、キャッシュメモリ領域が「一期一会のクエリプラン」で溢れかえるため、本当にキャッシュされるべきプランが追い出される（キャッシュスラッシング）。
正解：パラメータ化クエリの徹底
Spannerにおけるパラメータ化クエリは、単なるSQLインジェクション対策ではない。「プランキャッシュを効かせるための生命線」なのだ。
— ⭕ 正しいアプローチ：プレースホルダーを使用する
SELECT user_id, name, updated_at
FROM Users
WHERE status = @status AND age > @min_age;
このように記述することで、Spannerはクエリ構造（プラン）を一度だけコンパイルし、異なるパラメータ値をバインドして秒速で何千回も実行できる。
—
3. パラメータ化クエリにおける「最適化」の諸刃の剣：パラメータ・スニッフィング
パラメータ化クエリを使えば万事解決……とはいかないのが、Distributed Databaseの奥深いところだ。ここでパラメータ・スニッフィング（Parameter Sniffing）という悪名高い現象に直面する。
スニッフィングの悪夢
Spannerのオプティマイザは、「最初にそのキャッシュエントリが作成された（コンパイルされた）時に渡されたパラメータ値」を基準に、最適なプランを組むことがある。
例えば、以下のようなテーブルがあったとする。
- `Orders` テーブル（数千万件）
- カラム: `status` (‘PENDING’ は全体の0.001%, ‘COMPLETED’ は全体の99.9%)
1. 初回実行時にたまたま `@status = ‘COMPLETED’` が渡されたとする。
- オプティマイザの判断：「あぁ、全件の99.9%をスキャンするから、Full Table Scanのプランにしよう」
2. その後、常時飛んでくる `@status = ‘PENDING’`（0.001%のデータ）に対しても、この Full Table Scan のキャッシュされたプラン が使い回される。
- 結果：本来ならIndex Scanで一瞬で終わるはずのクエリが、毎回全件スキャン走り、レイテンシが跳ね上がる。
テックリードからの実践的処方箋
この罠を避ける、あるいは打破するためには以下の設計アプローチを取る。
1. オプティマイザヒントの活用
Spannerでは、クエリ内にヒントを埋め込むことで、オプティマイザの挙動を強制・誘導できる。
— 特定のインデックスの使用を強制するヒントの例
SELECT user_id, order_id
FROM Orders@{FORCE_INDEX=OrdersByStatus}
WHERE status = @status;
2. 統計情報の鮮度とメンテナンス
Spannerはバックグラウンドで自動的に統計情報を収集しているが、極端なデータスキュー（偏り）がある場合、オプティマイザが誤った判断を下しやすい。データの分布が劇的に変わるバッチ処理の直後などは、クエリの挙動変化に注意を払うこと。
—
4. 実務で活かす：堅牢なコネクション・セッション管理設計
前述した通り、プランキャッシュはセッションと深く結びついている。
アプリケーション（Go, Java, Node.js等）から Cloud Spanner Client Library を使用する際、セッションプールがどのように振る舞うかを理解していないと、プランキャッシュの恩恵を十分に受けられない。
セッションプールのアンチパターン
- リクエストごとにセッションを新規作成・破棄する: 論外。プランキャッシュが全く蓄積されず、毎回ウォームアップコストを支払うことになる。
- 過剰に多くのインスタンス間でセッションが分散する: クエリが特定のノードに偏らず、キャッシュのヒット率が頭打ちになる。
最適な設計指針
1. クライアントのライフサイクルをアプリの起動・終了に一致させる
Spannerのクライアントオブジェクトは、アプリケーション全体でシングルトン（唯一のインスタンス）として保持する。これにより、内部のセッションプールが適切にウォームアップされ、同一セッションへのクエリルーティングを通じてプランキャッシュの恩恵を最大化できる。
2. プレパレード・ステートメント（明示的プレパレーション）の活用
レイテンシに極端にシビアな高頻度トランザクションでは、明示的にクエリをプリパレードし、サーバー側でプランを固定化する手法も検討せよ。Client Libraryが提供するプリペアドステートメントの機能を正しくラップし、アプリ層でインスタンスをまたいだ無駄なコンパイルを排除するのだ。
—
5. まとめ：コードレビューのチェックリスト
明日から君のプロジェクトのコードレビューで、以下の項目を厳しくチェックしてほしい。
- [ ] リテラルの直書きはないか？ すべての動的値が `@param` 形式のパラメータ化クエリになっているか。
- [ ] ORMが変なSQLを生成していないか？ ORMの抽象化の裏で、意図しない動的SQLやリテラル埋め込みが行われていないか、発行されるSQLログ（Spannerの監査ログやインスペクタ）を確認したか。
- [ ] Clientのシングルトン担保 スパゲッティコードになりがちなレイヤーで、Spannerクライアントが乱立し、セッションプールが無駄に分断されていないか。
- [ ] スキューのあるクエリへの配慮 大量データを持つテーブルに対する検索で、インデックスが適切に使われているか、オプティマイザヒントの検討が必要なホットスポットはないか。
Cloud Spannerは、正しく扱えば無限の拡張性と圧倒的な一貫性をもたらす最強のデータベースだ。しかし、その内部構造（特にオプティマイザとプランキャッシュの挙動）を無視した雑なクエリは、システムの急成長期に必ず牙をむく。
「動けばいい」のフェーズは終わった。
今日から君の書くそのクエリは、プランキャッシュと完全に調和しているか？ 再度、コードを見直してほしい。
コメント