こんにちは！データベースの世界へようこそ。
今日は、PostgreSQLのパフォーマンスを語る上で避けては通れない、でも意外と勘違いされやすい「複合インデックスの並び順」についてお話ししようと思います。
「インデックスを貼れば速くなる！」と聞いて、とりあえず必要な列を全部詰め込んだインデックスを作って満足していませんか？実はそれ、「本棚の整理」に例えると、ちょっともったいないことをしているかもしれませんよ。
—
本棚で例える「インデックスの仕組み」
想像してみてください。あなたは巨大な図書館の司書さんです。何万冊もの本の中から、特定の1冊を探し出す必要があります。
もし、本を「著者名」と「出版年」で整理するとしたら、どう並べますか？
1. 「著者名」で並べてから、その中で「出版年」順に並べる
2. 「出版年」で並べてから、その中で「著者名」順に並べる
このどちらを選ぶかで、探しやすさが劇的に変わるんです。
1. 著者名 → 出版年 の順で並べた場合
「夏目漱石の、1910年に出版された本」を探すとき、まず「夏目漱石」のエリアに直行して、そこから1910年の本をパッと見つけられますよね。これはとても効率的です。
2. 出版年 → 著者名 の順で並べた場合
「夏目漱石の、1910年に出版された本」を探すとき、まず「1910年」の棚を見に行かなければなりません。1910年には何百人もの作家の本が並んでいますから、その中から「夏目漱石」を探すのは、さっきのやり方よりずっと大変そうです。
データベースの世界でも、これと全く同じことが起きています。
—
どの列を左側に持ってくるべき？
PostgreSQLで複合インデックス（複数の列を組み合わせたインデックス）を作るとき、一番左側に置く列は、「一番絞り込みが効く列」にするのが鉄則です。
日常の感覚で言うと、以下の2つのルールを意識してみてください。
- 「とりあえずこれがないと始まらない」という列を左に：
よく検索条件に使われる列、あるいは「値の種類が豊富で、一気に候補を絞り込める列」を左側に置きます。
- 「並び替え（ORDER BY）」を考慮する：
もしクエリが「特定の著者で絞って、出版年順に並べたい」というものなら、「著者名, 出版年」の順でインデックスを作ると、データベースは並び替えの手間を省いて結果を返してくれます。これができれば、クエリは爆速になります。
—
「とりあえず全部詰め込む」がダメな理由
「じゃあ、全部の列をインデックスに入れちゃえば最強じゃない？」と思うかもしれません。でも、実はそうでもないんです。
- インデックスも「重さ」がある：
インデックスもデータとして保存されます。列を増やせば増やすほど、インデックスのサイズは肥大化し、PostgreSQLがその中身を読み込むのに時間がかかるようになります。
- 更新が遅くなる：
データを新しく登録したり書き換えたりするたびに、インデックスも更新しなければなりません。詰め込みすぎたインデックスは、データの書き込み速度という「足かせ」になってしまうんです。
—
まとめ：今日からできる小さな工夫
最後に、明日からの開発で思い出してほしいポイントを3つだけまとめますね。
- 「絞り込みの強さ」を優先しよう： 検索条件で必ず使う列、値がバラバラな列を左側に。
- 「並び順」を味方にしよう： `ORDER BY` で使う列をインデックスの右側に置くと、ソートの手間が省けてハッピーになれます。
- 「過剰なインデックス」は控えめに： 実際にそのインデックスが使われているか、たまには `EXPLAIN` で確認してあげてくださいね。
インデックス設計は、いわば「整理整頓の美学」です。最初から完璧を目指さなくても大丈夫。まずは自分のクエリがどんなふうにデータを探しているのか、少し想像するところから始めてみましょう。
皆さんのデータベースが、今日も軽快に動きますように！また次回の記事でお会いしましょう。
コメント