Cloud Spannerにおける「クエリパラメータ」は、単なるセキュリティ対策ではない。
エンジニア諸君、コードレビューで「なぜ動的SQLを避けるべきか」を説くことに疲れてはいないか？
Cloud Spannerを触る以上、君たちは「単に動くコード」ではなく「数千億レコードの海でも沈まないコード」を書く責務がある。Cloud Spannerにおけるクエリパラメータの利用は、SQLインジェクションを防ぐための教科書的な作法である以前に、「Spannerの実行計画キャッシュエンジンを味方につけるための生命線」だ。
今日は、表面的なハウツーを超えた、Spannerアーキテクチャの深淵に触れる「クエリパラメータの真実」を共有する。
—
1. なぜ「文字列結合」がSpannerを殺すのか
まず、この最悪のアンチパターンを思い出してほしい。
— 絶対にやってはいけない例
— 文字列結合でクエリを構築する
SELECT FROM Users WHERE UserId = ‘user_12345′;
これをプログラム内で「`’user_’ + id`」のように構築して投げるのは、Spannerに対する冒涜だ。なぜなら、Spannerのクエリオプティマイザは、クエリ文字列そのものをハッシュ化してキャッシュのキーにするからだ。
`UserId = ‘user_12345’` と `UserId = ‘user_67890’` は、人間には同じ構造に見えても、Spannerにとっては「全く別のクエリ」として扱われる。結果、実行計画の再利用（Plan Cache Hit）が一切発生せず、毎回オプティマイザが解析コストを支払い、キャッシュメモリをゴミで埋め尽くすことになる。
2. パラメータ化クエリ：アーキテクチャ上の最適解
正しい実装はこうだ。
// Goでの実装例
stmt := spanner.Statement{
SQL: `SELECT FROM Users WHERE UserId = @userId`,
Params: map[string]interface{}{
“userId”: “user_12345”,
},
}
// これにより、SQLテンプレートが固定され、パラメータのみが差し替えられる。
なぜこれが「速い」のか
1. 実行計画の固定化: SpannerはSQLテンプレート（`SELECT … WHERE UserId = @userId`）に対して一度だけ最適な実行計画を作成し、キャッシュする。
2. 計算コストの排除: 2回目以降の実行では、オプティマイザの解析フェーズをスキップし、キャッシュ済みの計画を即座に適用する。
3. リソースの最適化: サーバー側で「プランのキャッシュ効率」が劇的に向上し、高負荷時のレイテンシ変動を抑え込める。
—
3. 実務で直面する「落とし穴」と設計パターン
現場のレビューでよく見かける「分かっているようで分かっていない」ポイントを指摘する。
落とし穴①：IN句のパラメータ化
「`WHERE Id IN (…)` をどう書くか？」という問いは、Spannerエンジニアの登竜門だ。個数が不定のIN句を無理やりパラメータ化しようとして、結局クエリを動的に再生成するケースがある。
ベストプラクティス:
- 要素数が固定なら `UNNEST` を使う。
- 要素数が可変なら、`ARRAY` パラメータを使うのが鉄則だ。
— クエリ側
SELECT FROM Users WHERE UserId IN UNNEST(@userIdList)
— アプリ側で配列を渡す
params := map[string]interface{}{
“userIdList”: []string{“u1”, “u2”, “u3”},
}
これで、`IN (u1, u2)` も `IN (u1, u2, u3, u4)` も、同じクエリテンプレートとしてキャッシュされる。これが「設計力」の差だ。
落とし穴②：型定義の厳密さ
Spannerは型に厳しい。パラメータの型定義が曖昧だと、インデックスが効かなくなることがある。特に `TIMESTAMP` や `NUMERIC` を扱う際は、クライアントライブラリ側で型を明示的に指定することを徹底せよ。暗黙の型変換が走ると、それはインデックス不適合を招くトリガーになる。
—
4. チーフアーキテクトからの提言
君たちが開発しているそのシステムは、1年後にデータ量が100倍になったとき、同じレスポンスを返せるだろうか？
- SQLを「コード」として扱うな: SQLは「データを取り出すための命令書」であり、実行計画という「最適化されたレシピ」に紐付いている。パラメータ化は、そのレシピを再利用可能にするための唯一の手段だ。
- ログを監視せよ: `Cloud Monitoring` で `Spanner Plan Cache Hit` 率を追え。ここが低いということは、君たちのクエリ構築ロジックがどこかで「動的生成の罠」に陥っている証拠だ。
- セキュリティは副産物: パラメータ化によってSQLインジェクションが防げるのは、エンジニアとしての最低限の安全装置に過ぎない。君たちが目指すべきは、その先にある「システムのスケーラビリティ」だ。
—
最後に。
コードレビューで部下が動的SQLを書いてきたら、こう言ってやれ。
「そのクエリは、Spannerのキャッシュを汚し、実行計画の再利用を阻害し、将来のスケールを殺している。今すぐパラメータ化し、プランキャッシュを神聖なものに戻せ」と。
技術を磨き続けろ。Spannerは、正しく扱えば裏切らない。
コメント