【実務・中級編】標準SQLサポート – Cloud Spanner

SpannerのSQLを「ただのデータベース言語」と誤解している君たちへ

Cloud Spannerの標準SQL（GoogleSQL）を触ったとき、多くのエンジニアは「MySQLやPostgreSQLと似ているから簡単だ」と安堵する。だが、その油断が本番環境でのレイテンシ爆発や、最悪の場合、システム全体の停止を招く。

Spannerは単なるリレーショナルデータベースではない。「水平分散された超巨大な計算機」だ。ここで使うSQLは、単なるデータの抽出命令ではなく、分散環境という過酷な戦場を生き抜くための「最適化指令書」であると心得るべきだ。

今日は、SpannerのSQLを極限まで使いこなすための勘所を伝授する。

—

1. 「JOIN」は魔法の杖ではない：分散結合のコストを知れ

RDBの経験が長いほど、脳死で`JOIN`を多用する。しかし、SpannerにおいてJOINは、ネットワークを跨いだデータのシャッフル（再配置）を意味する。

インターリーブ（Interleave）の活用:

親テーブルと子テーブルが物理的に同じスプリット（Split）に配置されていれば、JOINのコストは最小化される。設計の初期段階で`INTERLEAVE IN PARENT`を検討していないなら、それはもう敗北に近い。

Hash JoinとApply Joinの使い分け:

Spannerのクエリオプティマイザは優秀だが、神ではない。巨大なテーブル同士のJOINでは、`HASH JOIN`が選択される。これがメモリを食いつぶさないか、Explain Planで常に監視しろ。

2. 「WHERE句」でフルスキャンを防ぐ：インデックスの最適化

Spannerのクエリにおいて、インデックスは単なる検索速度向上のツールではない。「どれだけ不要な行を読みに行かずに済むか」という、I/O削減のための防波堤だ。

— 【NG例】インデックスが効かない典型（関数による加工）
SELECT FROM Users WHERE LOWER(email) = ‘example@gmail.com’;

— 【推奨】データ正規化と関数インデックス（Stored Column）の活用
— 大文字小文字を区別しない検索が必要なら、事前に正規化済みの列を持つか、
— GENERATED ALWAYS AS を使ったStored Columnをインデックス化せよ。
SELECT FROM Users WHERE normalized_email = ‘example@gmail.com’;

3. 分散環境特有の「ホットスポット」をSQLで避ける

クエリの書き方一つで、特定のノードに負荷が集中し、データベース全体を死に追いやる「ホットスポット」を作ってしまう。

スキャン範囲を意識する:

`ORDER BY`や`LIMIT`を伴うクエリで、インデックスの先頭列がカーディナリティの低い（値の種類が少ない）列だと、特定のノードにリクエストが集中する。

主キー設計との連動:

クエリのWHERE句が主キーの先頭列を含んでいるか？これを確認しないクエリは、本番に出してはならない。

4. 堅牢な設計のための「Explain Plan」の哲学

Spannerのコンソールで「実行計画（Explain Plan）」を見ずにSQLをコミットするのは、目隠しをして高速道路を運転するのと同じだ。

チェックすべきポイント:
1. Distributed Union: 複数のスプリットにまたがった検索が発生していないか。
2. Full Scan: インデックスが無視されて、全データ走査していないか。
3. Scalar Subquery: N+1問題を引き起こすような書き方になっていないか。

— 【クエリ最適化の鉄則】Explain Planを確認してからデプロイ
EXPLAIN ANALYZE
SELECT o.order_id, u.user_name
FROM Orders AS o
JOIN Users AS u ON o.user_id = u.user_id
WHERE o.created_at > ‘2023-01-01’;

— 実行計画を見て、Scanの種類と行数（Rows）を確認する。
— 数百万行をスキャンしているなら、インデックス設計の見直しが必須だ。

5. 結論：SpannerのSQLは「最適化への挑戦」である

Spannerが提供するANSI SQL準拠のインターフェースは、開発者の生産性を最大化するための「入り口」に過ぎない。しかし、その裏側で何が起きているかを想像できる者だけが、真にスケーラブルなシステムを構築できる。

JOINを減らし、インターリーブを増やす。
インデックスはクエリから逆算する。
Explain Planという「答え合わせ」を怠らない。

いいか、コードを書くときは常に「このクエリが100億行のデータの中でどう動くか」を頭の中でシミュレーションしろ。それが、我々エンジニアがSpannerを扱う上での最低限のマナーだ。

さあ、設計に戻れ。君たちの手元にあるそのクエリ、本当に最適化されているか？もう一度、その「実行計画」を見直してみろ。