インデックス用に選択された列は、行を適切に区別する必要があることを読みました。つまり、インデックス列には、同じ値を持つ多数の行が含まれてはなりません。これは、ブール値または性別などの列挙型がインデックスに適していないことを示唆しています。
しかし、性別でユーザーを見つけたいとします。私の特定のデータベースでは、ユーザーの 2% しか女性ではありません。その場合、女性ユーザーを取得するときは性別の列が有用なインデックスになるように思われますが、すべてを取得するときはそうではありません。男性ユーザー。
では、そのような列にインデックスを付けるのは一般的に良い考えでしょうか?
カーディナリティの低い列にインデックスを付けて検索パフォーマンスを向上させることは、私の世界では一般的です。Oracle は、このような状況向けに設計された「ビットマップ インデックス」をサポートしています。簡単な概要については、この記事を参照してください。
私の経験のほとんどは Oracle に関するものですが、他の RDBMS も同様のものをサポートしていると思います。
ただし、女性を選択する確率は約 2% であることを忘れないでください。残りの時間は、男性を探します。そのためには、(インデックス スキャンに加えてテーブルからデータにアクセスするよりも) ストレート テーブル スキャンの方が高速になります。
また、場合によっては、カーディナリティの低いカラム (enum、boolean) とカーディナリティの高いカラム (生年月日など) を組み合わせた複合インデックスを使用することもできます。これは、完全なデータと、実際に使用するクエリに大きく依存します。
私の経験では、男性/女性のインデックスが本当に役立つことはめったにありません. そして、一般的なアドバイスは有効です。覚えておくべきもう 1 つのポイント - 行を追加または削除 (または更新) するときは、インデックスを維持する必要があります。インデックスが多いほど、各変更操作で行う作業が増え、システムの速度が低下します。
インデックスの設計に関する書籍が丸ごとあります。
これは、インデックスをいつ作成するかをサーバーの統計情報から知らせてくれるケースです。このクエリが優勢になること、またはそのようなクエリを実行してもパフォーマンス目標を事前に達成できないことがわかっている場合を除き、時期尚早にインデックスを作成すると、パフォーマンスが向上するのではなく、パフォーマンスが低下する可能性があります。また、クエリを実際にどのように使用するかを検討することもできます。この場合、基準を満たすユーザーを単純に選択するのではなく、通常、この列に基づいて何らかの集計を行っていると思います。その場合、とにかくテーブル スキャンを実行することになり、インデックスは何も購入しません。