やあ。Cloud Spannerという、とてつもなく強力で、かつ少しだけ気難しい相棒と向き合おうとしている君へ。
Cloud Spannerは、世界中に散らばる巨大なデータを、まるで手元のノートに書かれたメモのように高速に扱えるデータベースだ。でも、その裏側では何千ものサーバーが複雑に連携している。
今日は、Spannerがどうやって「君の出した命令（クエリ）」を処理しているのか、その頭の中をのぞく「クエリ実行計画」の話をしよう。これを理解すれば、君はもうSpannerを使いこなす側の人間だ。
—
1. クエリ実行計画は「料理のレシピ」だ
君が「全ユーザーから、特定の条件に合う人を探して！」と命令したとき、Spannerはただ漫然とデータを探すわけじゃない。「どの順番で、どの材料を、どう調理するか」という綿密な計画を立てるんだ。これが「クエリ実行計画（Execution Plan）」だ。
もし料理が遅かったら、「野菜を切るのに時間がかかっているのか？」「そもそも冷蔵庫が遠すぎるのか？」を調べるよね。それと同じで、データベースが遅いときも、この「計画書」を見ればどこがボトルネックか一発でわかる。
—
2. 代表的な「動き」を知っておこう
Spannerの実行計画に出てくる「スキャンタイプ」には、いくつかの代表的なキャラクターがいる。これさえ知っておけば怖くない。
① Table Scan（本棚の全ページをめくる）
「本棚のすべての本を、最初から最後までめくって探す」という行為だ。
- 特徴: 非常に重い。データが少ないうちはいいけれど、数億行あるテーブルでこれをやると、Spannerは悲鳴を上げる。
② Index Scan（索引を使って目的のページへ飛ぶ）
「辞書の索引（インデックス）を見て、目的の単語があるページだけを開く」行為だ。
- 特徴: 超高速。Spannerを使うなら、必ずこの「索引」を賢く使うことが成功への近道だ。
③ Distributed Union（分身の術）
Spannerはデータを世界中に分散して持っている。だから、一つの作業を小さなグループに分け、「お前はこっちのサーバーを、お前はあっちのサーバーを調べてこい！」と指示を飛ばす。これがDistributed Unionだ。
- 特徴: チームプレーの要。これが頻発しすぎると、今度は「集計するリーダー役」に負荷が集中しすぎてしまうことがある。
—
3. チューニングの極意：無駄な動きを削ぎ落とせ
さあ、いよいよ実践だ。実行計画を見たとき、君が注目すべきは「どこで一番時間を食っているか」だ。
— 例えばこんなクエリを投げたとする
SELECT Name FROM Users WHERE Age > 20;
— 実行計画を見て、もし “Table Scan” があれば要注意！
— 「Age」に対してインデックスが貼られていない可能性が高い。
もし君が「Users」テーブルの「Age」列にインデックスを貼れば、SpannerはTable Scan（全部読み）からIndex Scan（索引読み）に計画を変更する。これで、実行速度は100倍、あるいは1000倍になることもある。
ここがポイント:
- スキャンする行数を減らす: 必要なデータだけを絞り込むこと。
- インデックスを信じる: 検索条件によく使う項目には、必ずインデックスを貼ること。
- 無駄な結合（Join）を避ける: テーブルをくっつけるのは意外とコストが高い。「本当にこのテーブルとくっつける必要があるか？」と自問自答しよう。
—
4. まとめ：君はもう「見通せる」エンジニアだ
クエリ実行計画を読むということは、Spannerという巨大なオーケストラの「指揮者のスコア」を読むことと同じだ。
1. まずは実行計画を眺める: 何が起きているのか、まずは全体像を見る。
2. コストが高い場所を探す: 実行計画の中で、時間がかかっているステップ（多くは行数が多いスキャン）を特定する。
3. インデックスで解決する: ほとんどの問題は、適切なインデックスを貼るだけで霧が晴れるように解決する。
難しく聞こえるかもしれないけれど、一度読めるようになると、データベースとの会話が楽しくなるはずだよ。「ああ、君は今、インデックスを使ってショートカットしようとしてくれているんだね」と、Spannerの努力が見えてくるから。
ここまでクリアすれば、君はもうSpannerの基本をバッチリマスターしたと言っていい。次は、もっと深い「データの持ち方（スキーマ設計）」の世界へ一緒に行こうか。
君のエンジニアとしての旅路が、より快適なものになることを応援しているよ。何か詰まったら、またいつでも聞いてくれ。
コメント