Je moet zeker wat tijd besteden aan het lezen over indexeren, er is veel over geschreven en het is belangrijk om te begrijpen wat er aan de hand is.
In grote lijnen legt een index een volgorde op aan de rijen van een tabel.
Stel je voor de eenvoud voor dat een tabel gewoon een groot CSV-bestand is. Telkens wanneer een rij wordt ingevoegd, wordt deze aan het einde ingevoegd . Dus de "natuurlijke" volgorde van de tabel is gewoon de volgorde waarin rijen zijn ingevoegd.
Stel je voor dat je dat CSV-bestand hebt geladen in een zeer rudimentaire spreadsheettoepassing. Het enige dat deze spreadsheet doet, is de gegevens weergeven en de rijen in sequentiële volgorde nummeren.
Stel je nu voor dat je alle rijen met een waarde "M" in de derde kolom moet vinden. Gezien wat je beschikbaar hebt, heb je maar één optie. U scant de tabel en controleert de waarde van de derde kolom voor elke rij. Als je veel rijen hebt, kan deze methode (een "tabelscan") lang duren!
Stel je nu voor dat je naast deze tabel een index hebt. Deze specifieke index is de index van waarden in de derde kolom. De index geeft alle waarden uit de derde kolom weer, in een zinvolle volgorde (bijvoorbeeld alfabetisch) en geeft voor elk ervan een lijst met rijnummers waar die waarde voorkomt.
Nu heb je een goede strategie om alle rijen te vinden waar de waarde van de derde kolom "M" is. U kunt bijvoorbeeld een binaire zoekopdracht uitvoeren ! Terwijl de tabelscan vereist dat u N rijen zoekt (waarbij N het aantal rijen is), vereist de binaire zoekopdracht in het ergste geval alleen dat u naar log-n indexitems kijkt. Wauw, dat is zeker een stuk makkelijker!
Als je deze index hebt, en je voegt rijen toe aan de tabel (aan het einde, want dat is hoe onze conceptuele tabel werkt), moet je de index natuurlijk elke keer bijwerken. U doet dus wat meer werk terwijl u nieuwe rijen schrijft, maar u bespaart een hoop tijd als u iets zoekt.
Over het algemeen creëert indexering dus een afweging tussen leesefficiëntie en schrijfefficiëntie. Zonder indexen kunnen invoegingen erg snel zijn -- de database-engine voegt gewoon een rij toe aan de tabel. Terwijl u indexen toevoegt, moet de engine elke index bijwerken tijdens het invoegen.
Aan de andere kant wordt het lezen een stuk sneller.
Hopelijk dekt dit uw eerste twee vragen (zoals anderen hebben beantwoord - u moet de juiste balans vinden).
Je derde scenario is iets gecompliceerder. Als u LIKE gebruikt, helpen indexeringsengines doorgaans met uw leessnelheid tot de eerste "%". Met andere woorden, als u WAAR kolom ZOALS 'foo%bar%' SELECTEERT, zal de database de index gebruiken om alle rijen te vinden waar de kolom begint met "foo", en vervolgens die tussenliggende rijenset moeten scannen om de subset te vinden die "bar" bevat. SELECTEER ... WAAR kolom ZOALS '%bar%' de index niet kan gebruiken. Ik hoop dat je kunt zien waarom.
Ten slotte moet u gaan nadenken over indexen op meer dan één kolom. Het concept is hetzelfde en gedraagt zich op dezelfde manier als de LIKE-dingen -- in wezen, als je een index op (a,b,c) hebt, zal de engine de index zo goed mogelijk van links naar rechts blijven gebruiken. Dus een zoekopdracht op kolom a zou de (a,b,c) index kunnen gebruiken, net als een op (a,b). De engine zou echter een volledige tabelscan moeten uitvoeren als u zocht WHERE b=5 AND c=1)
Hopelijk helpt dit een beetje licht te werpen, maar ik moet herhalen dat je het beste een paar uur kunt besteden aan het zoeken naar goede artikelen die deze dingen diepgaand uitleggen. Het is ook een goed idee om de documentatie van uw specifieke databaseserver te lezen. De manier waarop indices worden geïmplementeerd en gebruikt door queryplanners kan behoorlijk verschillen.