【入門編】インデックススキャン – PostgreSQL

こんにちは！データベースの世界へようこそ。
普段、何気なく使っているアプリやWebサイトの裏側で、データがどうやって見つけ出されているのか、不思議に思ったことはありませんか？

今日は、PostgreSQLの「インデックススキャン」という仕組みについて、少しだけお話しさせてください。エンジニアの現場では頻出する言葉ですが、実はこれ、皆さんの日常にある「あるもの」と全く同じ仕組みなんです。

—

突然ですが、あなたは今、500ページある分厚い料理本の「パスタのレシピ」を探しているとします。

もし、この本に「索引（インデックス）」がなかったらどうでしょう？最初のページから順番にめくって、パスタの文字が出てくるまで延々と探し続けますよね。これ、めちゃくちゃ時間がかかりますし、何より疲れますよね。

そこで活躍するのが、巻末の「索引」です。
「パスタ」という項目を探せば、「120ページに載っていますよ」と教えてくれる。私たちはそのページに直接ジャンプするだけでいい。

PostgreSQLの「インデックススキャン」は、まさにこれと同じことをやっているんです。

データベースも、中身は数万、数百万という膨大なデータの集まりです。何も対策をしていないと、データベースは最初から最後まで全ての行を舐めるようにチェックします。これを専門用語で「シーケンシャルスキャン（全件検索）」と呼ぶんですが、データが増えれば増えるほど、当然レスポンスは悪くなります。

そこで、特定の列に「インデックス」という名の付箋を貼ってあげる。そうすると、データベースはこう振る舞います。

1. インデックスという地図を見る（B-treeという構造を辿ります）
2. 「お目当てのデータはここにあるよ！」という住所を確認する
3. その場所へピンポイントで飛んでいく

これが「インデックススキャン」です。遠回りせずに、最短ルートで目的のデータにたどり着く。これが速さの秘訣なんです。

「じゃあ、全部の列にインデックスを貼れば最強じゃない？」と思うかもしれません。でも、ここで料理本の例えを思い出してください。

もし料理本に、100個も200個も索引が付いていたらどうなりますか？索引自体が本の厚みの半分を占めてしまって、本が重くなるし、索引を探すのすら面倒になりますよね。

データベースも同じです。

「インデックスは、必要な場所に、必要な分だけ貼る」。これが、現場で戦うエンジニアが最初に学ぶ「塩梅（あんばい）」なんです。

PostgreSQLがデータを探すときに、ただ闇雲に探すのではなく、賢く「インデックス」という地図を使って目的地へ向かう。これが、皆さんが普段快適にWebサイトを使えている理由の一つです。

まずはこのイメージを大切にしてみてください。仕組みがわかると、SQLを書くのが少しだけ楽しくなってきませんか？

もし今のクエリが少し遅いなと感じたら、「この検索、索引（インデックス）を貼る余地があるかな？」と、ぜひ思い返してみてくださいね。

それでは、また次回の記事でお会いしましょう！Happy Querying!