Zvažte, co je index v SQL – a index je ve skutečnosti část paměti ukazující na jiné části paměti (tj. ukazatele na řádky). Index je rozdělen na stránky, takže části indexu lze načíst a uvolnit z paměti v závislosti na využití.
Když požádáte o sadu řádků, SQL použije index k rychlejšímu vyhledání řádků než prohledávání tabulky (prohlížení každého řádku).
SQL má seskupené a neseskupené indexy. Seskupené indexy chápu tak, že seskupují podobné hodnoty indexu na stejnou stránku. Tímto způsobem, když požádáte o všechny řádky odpovídající hodnotě indexu, SQL může vrátit tyto řádky z seskupené stránky paměti. To je důvod, proč je pokus o seskupení indexu sloupce GUID špatný nápad – nepokoušíte se shlukovat náhodné hodnoty.
Když indexujete celočíselný sloupec, index SQL obsahuje sadu řádků pro každou hodnotu indexu. Pokud máte rozsah 1 až 10, pak byste měli 10 ukazatelů indexu. V závislosti na tom, kolik řádků existuje, lze toto stránkování různě. Pokud váš dotaz hledá index odpovídající "1" a poté kde Name obsahuje "Fred" (za předpokladu, že sloupec Name není indexován), SQL získá sadu řádků odpovídajících "1" velmi rychle, pak tabulka prohledá zbytek.
Takže to, co SQL ve skutečnosti dělá, je pokus o snížení pracovní sady (počet řádků), kterou musí iterovat.
Když indexujete bitové pole (nebo nějaký úzký rozsah), snížíte pracovní sadu pouze o počet řádků odpovídajících této hodnotě. Pokud máte malý počet odpovídajících řádků, značně by to snížilo vaši pracovní sadu. U velkého počtu řádků s rozdělením 50/50 vám to může přinést jen velmi malý nárůst výkonu v porovnání s udržováním indexu v aktuálním stavu.
Důvod, proč každý říká, že testujeme, je ten, že SQL obsahuje velmi chytrý a komplexní optimalizátor, který může ignorovat index, pokud se rozhodne, že skenování tabulek je rychlejší, nebo může použít řazení nebo může organizovat stránky paměti, jakkoli se mu to zatraceně líbí.