【いんでっくすせんりゃく】
インデックス戦略 とは?
最終更新:
💡 よくする検索に合わせ、必要な索引を選んで確かめる
よく使う問い合わせやデータ分布に合わせ、データベースの索引を設計・検証する方針。対象の列や列順、索引の種類などを検討する。検索を助ける一方で容量や更新の負担が増えるため、実行計画や実測で効果を確かめる。
📌 このページのポイント
索引は、たくさん作るほど速い?
使わない索引を増やしても、検索が必ず速くなるわけではないよ。保存領域が必要で、データの変更に合わせた保守の負担もある。よく使う問い合わせから、役に立つ候補を考えよう。
どの列に、作ればよいの?
検索条件やJOIN、並べ替えなどを確認するよ。どのくらいの行を返すか、値の分布、更新頻度も判断材料。値の種類が少なくても、特定の値がまれなら絞り込みに役立つ場合があるんだ。
複合索引の列順は、どう決める?
方式やDBによるよ。PostgreSQLのB-treeは先頭側の条件が重要だけれど、種類数が多い列を機械的に先頭へ置くものではない。よく使う等値条件や範囲条件に合わせて設計しよう。
先頭の列を検索しなければ、使えない?
必ず使えないわけではないよ。PostgreSQL 18のB-treeでは、後ろの列の条件でskip scanが有利になる場合もある。使うかは分布や実行計画によるので、一般則だけで決めつけないでね。
効果は、どう確かめるの?
もっと詳しく知りたい人へ
必要な列を全部索引に入れると、テーブルを読まなくて済む?
必ずではありません。PostgreSQLでは索引方式や必要な列などの条件に加え、行が現在の問い合わせから見えるかの確認があります。Index Only Scanでも、visibility mapの状態によってテーブル側を読む場合があります。列を追加すれば容量も増えるため、実行計画と実測で確認します。
まとめ:ざっくりこれだけ覚えればOK!
「インデックス戦略」って出てきたら「よく使う検索に合う索引を設計し、効果を確かめる方針」と思えばだいたいOK!
📖 おまけ:英語の意味
「Index strategy」 = 索引の設計方針
💬 本の索引を、読者がよく探す項目に合わせて用意するイメージだよ。DBでは問い合わせやデータの分布に合わせて設計するんだ。