こんにちは！データベースの世界へようこそ。
PostgreSQLのアーキテクチャについて語るとなると、つい専門用語を並べたくなってしまうのですが、今日はあえて「道具」や「日常」に例えて、一番の要である「インデックススキャン」についてお話ししようと思います。
皆さんは、図書館で本を探すとき、どうやって探しますか？
インデックスは「本の巻末索引」と同じ
もし、何万冊もある本の中から特定のテーマの本を探すとき、一冊ずつ本棚の端から端まで見て回るなんて、気が遠くなりますよね。そんなことをしていたら、日が暮れてしまいます。
そこで、私たちは「索引」を使います。巻末の索引を見て、目的のキーワードが載っているページ番号を確認し、そのページをパッと開きますよね。
PostgreSQLの「インデックススキャン」も、まさにこれと全く同じことをやっているんです。
—
テーブル全体を調べるのは「全読み」
インデックスを使わない検索、いわゆる「シーケンシャルスキャン（全テーブル走査）」は、図書館で「適当に本棚の端から端まで順番に覗いていく」ようなものです。
データが数件ならいいのですが、数百万件、数千万件となってくると、データベースはハァハァ言いながら汗だくで探すことになります。これが、「検索が遅い！」と感じる一番の原因ですね。
インデックススキャンが「スマートな理由」
インデックススキャンは、いわば「近道」です。
1. インデックスという地図を見る: 探し物がどこにあるかを示す小さな索引（インデックス）をまず見に行きます。
2. 目的地の番地を確認する: そこには「このデータは、テーブルのこの場所（物理的な住所）にありますよ」というメモが書かれています。
3. 直接そこへ飛ぶ: データベースは、無駄な寄り道をせず、ピンポイントでそのデータを取りに行きます。
この「地図を見て、目的地に直行する」という動きのおかげで、データがどれだけ膨大になっても、驚くほど速く答えを見つけ出せるわけです。
—
もちろん、良いことばかりじゃないんです
「じゃあ、全部の列にインデックスを作れば最強じゃない？」と思うかもしれません。でも、ここがエンジニアの腕の見せ所。
図書館の例で言うと、本の内容が変わるたびに、何百ページもの索引を全部書き直すのは大変ですよね。それと同じで、インデックスをたくさん作りすぎると、データを新しく追加したり書き換えたりするたびに、データベースはその「地図」も一生懸命更新しないといけなくなります。
- インデックスが多い: 検索は爆速になるけど、データの保存や更新は少し重くなる。
- インデックスが少ない: データの保存は軽快だけど、検索がすごく遅くなる。
このバランスを考えるのが、データベース設計の面白くて奥深いところなんです。
最後に
インデックススキャンは、データベースが「いかに効率よく、無駄な体力を使わずに答えを出すか」を追求した、工夫の結晶のような仕組みです。
もし今度、皆さんが書いたプログラムで「検索が遅いな」と感じたら、ぜひ思い出してみてください。「あ、これ今、図書館の端から端まで探し回っているのかも？」って。
そう思ったら、インデックスという名の「索引」を作ってあげるだけで、世界がガラッと変わるはずですよ。
それでは、また次回の記事でお会いしましょう！データベースの世界を楽しんでくださいね。
コメント