Du bør bestemt bruge lidt tid på at læse op på indeksering, der er skrevet meget om det, og det er vigtigt at forstå, hvad der foregår.
I store træk pålægger et indeks en rækkefølge på rækkerne i en tabel.
For enkelthedens skyld kan du forestille dig, at en tabel kun er en stor CSV-fil. Hver gang en række indsættes, indsættes den til sidst . Så den "naturlige" rækkefølge af tabellen er bare den rækkefølge, rækkerne blev indsat i.
Forestil dig, at du har den CSV-fil indlæst i et meget rudimentært regnearksprogram. Alt dette regneark gør er at vise dataene og nummerere rækkerne i sekventiel rækkefølge.
Forestil dig nu, at du skal finde alle de rækker, der har en eller anden værdi "M" i den tredje kolonne. I betragtning af hvad du har til rådighed, har du kun én mulighed. Du scanner tabellen og kontrollerer værdien af den tredje kolonne for hver række. Hvis du har mange rækker, kan denne metode (en "tabelscanning") tage lang tid!
Forestil dig nu, at du ud over denne tabel har et indeks. Dette særlige indeks er indekset over værdier i den tredje kolonne. Indekset viser alle værdierne fra den tredje kolonne i en eller anden meningsfuld rækkefølge (f.eks. alfabetisk) og giver for hver af dem en liste over rækkenumre, hvor værdien vises.
Nu har du en god strategi til at finde alle de rækker, hvor værdien af den tredje kolonne er "M". For eksempel kan du udføre en binær søgning ! Hvor tabelscanningen kræver, at du kigger på N rækker (hvor N er antallet af rækker), kræver den binære søgning kun, at du ser på log-n indeksindgange, i allerværste tilfælde. Wow, det er helt sikkert meget nemmere!
Selvfølgelig, hvis du har dette indeks, og du tilføjer rækker til tabellen (i slutningen, da det er sådan vores konceptuelle tabel fungerer), skal du opdatere indekset hver gang. Så du gør lidt mere arbejde, mens du skriver nye rækker, men du sparer masser af tid, når du søger efter noget.
Så generelt skaber indeksering en afvejning mellem læseeffektivitet og skriveeffektivitet. Uden indekser kan indsættelser være meget hurtige -- databasemotoren tilføjer bare en række til tabellen. Når du tilføjer indekser, skal motoren opdatere hvert indeks, mens du udfører indsættelsen.
På den anden side bliver læsninger meget hurtigere.
Forhåbentlig dækker det dine første to spørgsmål (som andre har svaret -- du skal finde den rigtige balance).
Dit tredje scenarie er lidt mere kompliceret. Hvis du bruger LIKE, vil indekseringsmotorer typisk hjælpe med din læsehastighed op til den første "%". Med andre ord, hvis du vælger WHERE-kolonnen SOM 'foo%bar%', vil databasen bruge indekset til at finde alle de rækker, hvor kolonnen starter med "foo", og skal derefter scanne det mellemliggende rækkesæt for at finde undersættet der indeholder "bar". SELECT ... WHERE-kolonnen LIKE '%bar%' kan ikke bruge indekset. Jeg håber, du kan se hvorfor.
Til sidst skal du begynde at tænke på indekser på mere end én kolonne. Konceptet er det samme og opfører sig på samme måde som LIKE-tingene - i det væsentlige, hvis du har et indeks på (a,b,c), vil motoren fortsætte med at bruge indekset fra venstre mod højre så godt den kan. Så en søgning på kolonne a kan bruge (a,b,c)-indekset, ligesom en på (a,b). Motoren skal dog lave en fuld tabelscanning, hvis du søgte WHERE b=5 OG c=1)
Forhåbentlig hjælper dette med at kaste lidt lys, men jeg må gentage, at det er bedst for dig at bruge et par timer på at grave rundt efter gode artikler, der forklarer disse ting i dybden. Det er også en god idé at læse din særlige databaseservers dokumentation. Den måde, indekser implementeres og bruges af forespørgselsplanlæggere, kan variere ret meget.