Tänk på vad ett index är i SQL - och index är verkligen en minnesbit som pekar på andra minnesbitar (d.v.s. pekare till rader). Indexet är uppdelat i sidor så att delar av indexet kan laddas och laddas ur minnet beroende på användning.
När du frågar efter en uppsättning rader använder SQL indexet för att hitta raderna snabbare än tabellskanning (tittar på varje rad).
SQL har klustrade och icke-klustrade index. Min uppfattning om klustrade index är att de grupperar liknande indexvärden på samma sida. På detta sätt när du frågar efter alla rader som matchar ett indexvärde, kan SQL returnera dessa rader från en klustrad minnessida. Det är därför det är en dålig idé att försöka klusterindexera en GUID-kolumn - du försöker inte klustera slumpmässiga värden.
När du indexerar en heltalskolumn innehåller SQLs index en uppsättning rader för varje indexvärde. Om du har ett intervall på 1 till 10, så skulle du ha 10 indexpekare. Beroende på hur många rader det finns kan detta sökas på olika sätt. Om din fråga letar efter indexet som matchar "1" och sedan där Namn innehåller "Fred" (förutsatt att kolumnen Namn inte är indexerad), får SQL uppsättningen rader som matchar "1" mycket snabbt, sedan skannar tabellen för att hitta resten.
Så vad SQL verkligen gör är att försöka minska arbetsuppsättningen (antal rader) som den måste iterera över.
När du indexerar ett bitfält (eller något smalt område) minskar du bara arbetsuppsättningen med antalet rader som matchar det värdet. Om du har ett litet antal rader som matchar det skulle minska din arbetsuppsättning mycket. För ett stort antal rader med 50/50-fördelning kan det ge dig mycket liten prestandavinst jämfört med att hålla indexet uppdaterat.
Anledningen till att alla säger att man ska testa är för att SQL innehåller en mycket smart och komplex optimerare som kan ignorera ett index om den bestämmer att tabellskanning är snabbare, eller kan använda en sortering, eller kan organisera minnessidor hur den förbannat vill.