Deux situations rendent un index peu utile, voire inutile.

Faible cardinalité : une colonne avec très peu de valeurs distinctes par rapport au nombre de lignes — un statut qui ne vaut que 'actif' ou 'inactif' sur une table d'un million de lignes, par exemple. Un index dessus ne réduit presque rien : chaque valeur concerne malgré tout des centaines de milliers de lignes, la base doit de toute façon en lire une grande partie.

Petite table : sur une table de quelques dizaines ou centaines de lignes, parcourir la table entière (un « scan séquentiel ») est déjà très rapide — l'aller-retour supplémentaire par un index peut même s'avérer plus lent qu'une lecture directe. Le moteur SQL choisit d'ailleurs souvent lui-même d'ignorer un index existant dans ce cas.

À retenir :

• Un index sur une colonne à faible cardinalité (peu de valeurs distinctes) apporte un gain limité, voire négligeable, sur une grosse table.
• Sur une toute petite table, un index n'est généralement pas nécessaire pour de bonnes performances.
• Un index reste surtout rentable sur une colonne à forte cardinalité (beaucoup de valeurs distinctes), utilisée dans les filtres d'une table volumineuse.

À vous de jouer : un index sur une colonne booleen_actif (seulement vrai/faux) apporterait-il un grand bénéfice sur une table de 50 millions de lignes ? Justifiez.