Et indeks kan hjælpe selv på felter med lav kardinalitet, hvis:
-
Når en af mulige værdier er meget sjælden sammenlignet med de andre værdier, og du søger efter den.
For eksempel er der meget få farveblinde kvinder, så denne forespørgsel:
SELECT * FROM color_blind_people WHERE gender = 'F'
ville højst sandsynligt have gavn af et indeks på
gender
. -
Når værdierne har tendens til at blive grupperet i tabelrækkefølgen:
SELECT * FROM records_from_2008 WHERE year = 2010 LIMIT 1
Selvom der kun er
3
særskilte år her, poster med tidligere år er højst sandsynligt tilføjet først, så rigtig mange poster ville skulle scannes før returnering af den første2010
optag, hvis ikke for indekset. -
Når du har brug for
ORDER BY / LIMIT
:SELECT * FROM people ORDER BY gender, id LIMIT 1
Uden indekset, en
filesort
ville være påkrævet. Selvom det er noget optimeret tilLIMIT
, vil det stadig kræve en fuld tabelscanning. -
Når indekset dækker alle felter, der bruges i forespørgslen:
CREATE INDEX (low_cardinality_record, value) SELECT SUM(value) FROM mytable WHERE low_cardinality_record = 3
-
Når du har brug for
DISTINCT
:SELECT DISTINCT color FROM tshirts
MySQL
vil brugeINDEX FOR GROUP-BY
, og hvis du har få farver, vil denne forespørgsel være øjeblikkelig selv med millioner af poster.Dette er et eksempel på et scenarie, hvor indekset på et felt med lav kardinalitet er mere effektiv end det på et felt med høj kardinalitet.
Bemærk, at hvis DML
ydeevne er ikke meget på et problem, så er det sikkert at oprette indekset.
Hvis optimizer mener, at indekset er ineffektivt, vil indekset bare ikke blive brugt.