Du bör definitivt lägga lite tid på att läsa på om indexering, det finns mycket skrivet om det, och det är viktigt att förstå vad som händer.
I stort sett lägger ett index en ordning på raderna i en tabell.
För enkelhetens skull, föreställ dig att en tabell bara är en stor CSV-fil. Närhelst en rad infogas infogas den i slutet . Så den "naturliga" ordningen i tabellen är bara den ordning som raderna infogades i.
Föreställ dig att du har den där CSV-filen laddad i ett mycket rudimentärt kalkylarksprogram. Allt detta kalkylblad gör är att visa data och numrera raderna i sekventiell ordning.
Föreställ dig nu att du måste hitta alla rader som har något värde "M" i den tredje kolumnen. Med tanke på vad du har tillgängligt har du bara ett alternativ. Du skannar tabellen och kontrollerar värdet på den tredje kolumnen för varje rad. Om du har många rader kan den här metoden (en "tabellskanning") ta lång tid!
Föreställ dig nu att du förutom den här tabellen har ett index. Detta specifika index är indexet för värden i den tredje kolumnen. Indexet listar alla värden från den tredje kolumnen, i någon meningsfull ordning (t.ex. alfabetiskt) och ger för vart och ett av dem en lista med radnummer där det värdet visas.
Nu har du en bra strategi för att hitta alla rader där värdet på den tredje kolumnen är "M". Du kan till exempel utföra en binär sökning ! Medan tabellskanningen kräver att du tittar på N rader (där N är antalet rader), kräver den binära sökningen bara att du tittar på log-n-indexposter, i allra värsta fall. Wow, det är säkert mycket enklare!
Naturligtvis, om du har det här indexet, och du lägger till rader i tabellen (i slutet, eftersom det är så vår konceptuella tabell fungerar), måste du uppdatera indexet varje gång. Så du gör lite mer arbete medan du skriver nya rader, men du sparar massor av tid när du söker efter något.
Så i allmänhet skapar indexering en avvägning mellan läseffektivitet och skriveffektivitet. Utan index kan insättningar vara mycket snabba -- databasmotorn lägger bara till en rad i tabellen. När du lägger till index måste motorn uppdatera varje index samtidigt som infogningen utförs.
Å andra sidan blir läsningen mycket snabbare.
Förhoppningsvis täcker det dina två första frågor (som andra har svarat -- du måste hitta rätt balans).
Ditt tredje scenario är lite mer komplicerat. Om du använder LIKE kommer indexeringsmotorer vanligtvis att hjälpa till med din läshastighet upp till den första "%". Med andra ord, om du väljer WHERE-kolumnen SOM "foo%bar%", kommer databasen att använda indexet för att hitta alla rader där kolumnen börjar med "foo", och sedan behöva skanna den mellanliggande raduppsättningen för att hitta delmängden som innehåller "bar". SELECT ... WHERE-kolumnen LIKE '%bar%' kan inte använda indexet. Jag hoppas att du förstår varför.
Slutligen måste du börja tänka på index på mer än en kolumn. Konceptet är detsamma och beter sig på samma sätt som LIKE-grejen -- i huvudsak, om du har ett index på (a,b,c), kommer motorn att fortsätta använda indexet från vänster till höger så gott den kan. Så en sökning på kolumn a kan använda indexet (a,b,c), precis som en på (a,b). Motorn skulle dock behöva göra en fullständig tabellsökning om du sökte WHERE b=5 OCH c=1)
Förhoppningsvis bidrar detta till att kasta lite ljus, men jag måste upprepa att det är bäst att du spenderar några timmar på att leta efter bra artiklar som förklarar dessa saker på djupet. Det är också en bra idé att läsa dokumentationen för just din databasserver. Sättet som index implementeras och används av frågeplanerare kan variera ganska mycket.