Ein Index wird normalerweise in aufsteigender Reihenfolge abgelegt. Deshalb ind Sortierungen über ein indiziertes Feld meist schneller.
Es gibt aber auch einen gewissen Overhead um vom Index auf den passenden Datensatz zu springen.
Angenommen du hast zum Beispiel 2 Tabellen:
Code:
Master:
PK integer, -- Primärschlüssel
Name varchar(55)
Detail:
PK integer, -- Primärschlüssel
FK integer, -- Fremdschlüssel auf Master.PK
SomeValue varchar(55)
Die Mastertabelle enthält 10 Datensätze, die Detailtabelle 1.000.
Jetzt fragst du in der Detailtabelle alle Datensätze nach einem bestimmten Masterdatensatz ab (zum Bsp.: WHERE FK = 5).
Wenn das Feld FK indiziert ist, muss die
DB nur 10 verschiedene Möglichkeiten durchlaufen, da der Index auch noch sortiert ist läuft sie nur die ersten 5 durch.
Das heißt, du hast auf eine sehr ökonomische Art die Ergebnismenge auf ca. 100 Datensätze reduziert.
Eine Indexsuche auf den PK muss nicht schneller sein, da er zu jedem Indexwert den "richtigen" Datensatz suchen muss.
Suchst du zum Beispiel nach ...
WHERE (PK between 1 and 5) and Name like 'A%'
...muss er für jede Zeile erst im Index suchen, danach den passenden Datensatz finden um schließlich darin nach dem Namen zu suchen.
Da der Index aber sortiert abgelegt wird, werden Bedingungen, die nur indizierte Felder einschließen massiv schneller.
Ein großer Nachteil von Indizes ist die Tatsache, dass sämtliche Datenänderungen langsamer werden (Die Sortierung muss ja neu aufgebaut werden).
Man muss also immer abwiegen, ob ein Index an dem Feld Sinn macht. Foreign Keys würde ich zum Beispiel immer indizieren, Prim Keys auch (Man greift ja oft direkt über den PK auf die Daten zu).