【実務・中級編】クエリ最適化ヒント – Cloud Spanner

Cloud Spannerのオプティマイザを「手懐ける」――クエリヒントを武器にする極意

Cloud Spannerは、分散トランザクションと強整合性を両立させた怪物だ。しかし、多くのエンジニアが陥る罠がある。それは「オプティマイザが常に最適解を見つけてくれる」という甘い幻想だ。

確かにSpannerのクエリエンジンは洗練されている。だが、数百万行、数千万行が交差する複雑なデータモデルにおいて、統計情報だけでは判断を誤ることもある。オプティマイザが「最速のルート」を見失ったとき、我々エンジニアがとるべき行動は、ただ一つ。クエリヒントで「正解」を明示することだ。

今回は、現場で泥臭くSpannerを使い倒してきた経験から、クエリヒントの核心を叩き込む。

—

1. なぜ「FORCE_JOIN_ORDER」が聖域を侵すのか

大規模なJOINにおいて、最もコストを左右するのは「結合順序」だ。Spannerのオプティマイザは原則として、データ量やインデックス状況から最もコストが低い順序を選択する。しかし、実行計画が「直感に反する」場合がある。

FORCE_JOIN_ORDER の鉄則

`FORCE_JOIN_ORDER` を使うということは、オプティマイザの判断を無視し、あなたが「この順序が最強だ」と宣言することを意味する。

巨大な Orders テーブルと Users テーブルを結合する際、
絞り込み条件が強い Users を先にスキャンさせたい場合のヒント例

/
SELECT /@ FORCE_JOIN_ORDER=TRUE /
u.user_id, o.order_id
FROM Users AS u
JOIN Orders AS o ON u.user_id = o.user_id
WHERE u.status = ‘ACTIVE’;

【チーフアーキテクトの視点】
`FORCE_JOIN_ORDER=TRUE` を使う前に、まずは `EXPLAIN ANALYZE` を叩け。インデックスが効いていないのか、統計情報が古いのか。ヒントで解決するのは、「統計情報では判断できない論理的な結合の優位性」がある場合のみだ。安易な多用は、将来のデータ増加時に「手動で指定した順序」がボトルネックになるという技術的負債を生む。

—

2. JOIN_METHOD：ハッシュか、それともループか

Spannerは主に `HASH JOIN` と `APPLY JOIN` (Nested Loop Join) を使い分ける。

HASH JOIN: 大規模なデータセット同士を結合する際に有利。メモリ消費は大きいが、並列処理能力が高い。
APPLY JOIN: 片方のテーブルが非常に小さい、あるいはインデックス経由で1行をピンポイントで取得できる場合に無双する。

実践：APPLY JOINの強制

マスタテーブルのような極小データと、トランザクションテーブルを結合するなら、迷わず `APPLY JOIN` を誘導せよ。

SELECT /@ JOIN_METHOD=APPLY_JOIN /
p.product_name, s.sale_amount
FROM Products AS p
JOIN Sales AS s ON p.product_id = s.product_id
WHERE p.category = ‘Electronics’; — カテゴリが極端に絞られる場合

【警告】
`JOIN_METHOD=HASH_JOIN` を強制したい場合は要注意だ。メモリ不足（OOM）でクエリが死ぬリスクが跳ね上がる。基本はオプティマイザを信じ、どうしてもAPPLY JOINが選択されない「エッジケース」にのみ使うのがプロの流儀だ。

—

3. クエリ最適化の「守破離」

技術は「使えばいい」ものではない。以下のステップで適用を判断せよ。

1. 守：統計情報の鮮度を疑う
ヒントを検討する前に、`ANALYZE`コマンドで統計情報をリフレッシュしたか？これだけで解決するケースが8割だ。
2. 破：実行計画の不自然なコストを見抜く
`EXPLAIN ANALYZE` の実行コストを見ろ。全件スキャンが発生しているなら、ヒントの前にインデックスの貼り方を見直すべきだ。
3. 離：ヒントで強引に最適化する
これら全てを試した上で、なおパフォーマンスが出ない場合のみ、ヒントを刻め。その際、必ずコード内に「なぜこのヒントが必要か」という設計意図をコメントに残せ。

—

4. 最後に：エンジニアへの提言

Cloud Spannerは「魔法の箱」ではない。分散データベースの物理的な制約を理解し、クエリエンジンと対話する。それができるエンジニアだけが、億単位のレコードをミリ秒で捌くシステムを構築できる。

クエリヒントは、オプティマイザへの「最後通牒」だ。
「君の判断は尊重するが、このケースだけは俺の言う通りに動け」
そう胸を張って言えるほど、クエリとデータの関係性を深く理解してほしい。

もし、どうしてもクエリが遅くて夜も眠れないというなら、まずはSchema設計から見直せ。ヒントは劇薬だ。用法・用量を守り、正しく使いこなしてほしい。

健闘を祈る。