「探す」時間を劇的に減らす！PostgreSQLのB-treeインデックスの秘密
こんにちは！データベースの世界へようこそ。
皆さんは、分厚い本の中から特定の単語を探すとき、どうしていますか？一ページずつ最初から最後までめくる人は、まずいないはずです。巻末の「索引（インデックス）」を見て、何ページにあるかを確認してから目的のページに飛びますよね。
実は、PostgreSQLの「B-treeインデックス」も、これと全く同じことをしています。今日は、このインデックスがなぜこれほどまでに優秀なのか、そしてどうやって賢く使うとクエリが爆速になるのかを、一緒に紐解いていきましょう。
—
B-treeって、結局なにもの？
B-tree（ビーツリー）は、データベースで最もよく使われるインデックスの形です。イメージとしては「整理整頓された階層構造」です。
例えば、図書館の蔵書管理を想像してみてください。
- まず「あ〜さ行」「た〜わ行」という大きな看板がある。
- その次に、「あ行」の中の「あ〜お」という棚がある。
- 最後に、個別の本が並んでいる。
こうやって枝分かれ（Tree）させて整理されているから、膨大なデータの中からでも、ほんの数ステップで目的のデータにたどり着けるんです。
B-treeが最強な理由
この構造のすごいところは、「等価比較（＝）」にも「範囲検索（＞や＜）」にも強いこと。
「名前が佐藤さん」を探すのも、「売上が100万円から200万円の間」を探すのも、この整理棚をたどれば一瞬です。これが、PostgreSQLでインデックスといえばまずはB-tree、と言われる理由ですね。
—
「インデックススキャン」と「インデックスオンリースキャン」
さて、ここからが少しだけテクニカルな話ですが、めちゃくちゃ面白いところです。データベースがデータを探すとき、2つの「賢いやり方」があります。
1. インデックススキャン（索引を見て、本を開く）
これは、索引でページ数を確認してから、実際にそのページを開きに行く動作です。「佐藤さんの住所を知りたい」というとき、索引で「佐藤＝105ページ」と見つけ、本棚（実際のデータテーブル）まで本を取りに行く。これが通常のインデックススキャンです。
2. インデックスオンリースキャン（索引だけで完結させる！）
これができたら最高です。もし、索引の中に「佐藤さんの電話番号」まで書かれていたらどうでしょう？わざわざ重たい本を開かなくても、索引を見ただけで答えがわかりますよね。
これをデータベースの世界では「インデックスオンリースキャン」と呼びます。
インデックスの中に必要な情報が全て揃っていれば、本体のデータを見に行く必要がないので、驚くほど速いんです！
—
パフォーマンスを上げるための「ちょっとしたコツ」
では、どうすればこの「オンリースキャン」を引き出せるのか？ 実は、少しの工夫でクエリの速度は劇的に変わります。
- 必要な列だけをSELECTする：
`SELECT ` で全部の列を持ってくるのではなく、本当に必要な列だけを指定しましょう。インデックスにその列が含まれていれば、オンリースキャンが発動する可能性がグッと高まります。
- 複合インデックスの活用：
「苗字」と「名前」をセットでよく検索するなら、それらをセットにした「複合インデックス」を作ると、検索効率がさらに上がりますよ。
—
最後に：完璧を目指しすぎないことも大切
インデックスは便利ですが、貼れば貼るほどいいというわけではありません。
本で例えるなら、索引を何十種類も作ったら、それだけで分厚い本になってしまいますよね。データが新しく追加されるたびに、その全ての索引を書き直さないといけないので、逆に動作が重くなってしまうんです。
「よく検索する条件」を見極めて、そこにピンポイントでインデックスを貼る。この「引き算の感覚」が、優れたデータベースエンジニアへの第一歩です。
皆さんのデータベースが、今日もサクサク快適に動きますように！
また次回の記事でお会いしましょう。質問などあれば、いつでも気軽にコメントしてくださいね。
コメント