Utilisation de colonnes booléennes ou enum dans les index?

Question

J'ai lu que les colonnes qui sont choisies pour les index devraient bien discriminer entre les lignes, c'est-à-dire que les colonnes d'index ne devraient pas contenir un grand nombre de lignes ayant la même valeur. Cela suggère que les booléens ou une énumération comme le genre serait un mauvais choix pour un index. Mais disons que je veux trouver les utilisateurs par sexe et dans ma base de données, seulement 2% des utilisateurs sont des femmes, alors dans ce cas, il semble que la colonne de genre serait un index utile pour obtenir les utilisateurs féminins, mais pas lors de l'obtention de tous les utilisateurs masculins.

Alors serait-il généralement une bonne idée de mettre un index sur une telle colonne?

Answer 1

C'est un cas où je laisserais les statistiques du serveur me informent quand créer l'index. À moins que vous sachiez que cette requête va prédominer ou que l'exécution d'une telle requête n'atteindrait pas vos objectifs de performance a priori, la création prématurée de l'index peut vous coûter juste au lieu de l'augmenter. En outre, vous voudrez peut-être réfléchir à la manière dont vous utiliseriez la requête. Dans ce cas, je suppose que vous feriez typiquement une sorte d'agrégation basée sur cette colonne plutôt que de simplement sélectionner les utilisateurs qui répondent aux critères. Dans ce cas, vous effectuerez l'analyse de la table de toute façon et l'index ne vous achètera rien.

Answer 2

L'indexation d'une colonne à faible cardinalité pour améliorer les performances de recherche est courante dans mon monde. Oracle prend en charge un "index bitmap" conçu pour ces situations. Voir this article pour un bref aperçu.

La plupart de mon expérience est avec Oracle, mais je suppose que d'autres soutiens « SGBDR quelque chose de similaire.

Answer 3

Ne pas oublier, cependant, que vous serez probablement sélection pour les femmes d'environ 2% du temps. Le reste du temps, vous serez à la recherche de mâles. Et pour cela, un scan de table direct (plutôt qu'un scan d'index plus l'accès aux données de la table) va être plus rapide.

Vous pouvez également, parfois, utiliser un index composé, avec une colonne de cardinalité basse (enum, boolean) couplée à une colonne de cardinalité plus élevée (date de naissance, peut-être). Cela dépend beaucoup des données complètes et des requêtes que vous utiliserez vraiment.

Mon expérience est qu'un index sur mâle/femelle va rarement être vraiment utile. Et le conseil général est valide. Un autre point à retenir: les index doivent être conservés lorsque vous ajoutez ou supprimez (ou mettez à jour) des lignes. Plus il y a d'index, plus chaque opération de modification a du travail, ce qui ralentit le système.

Il existe des livres entiers sur la conception d'index.