Abfrageoptimierung

[Andreas Müller]

Hallo Sebastian, 

> du brauchst einen Index über die Spalten die in der Abfrage im ORDER,
> WHERE oder JOIN Teil vorkommen, und die Reihenfolge ist natürlich auch
> noch relevant

die Reihenfolge ist in der Regel nur bei unvollständigen Index Schlüsseln
relevant oder eben für die ORDER BY Optimierung. Für eine WHERE Konditionen
ist es in der Regel unerheblich ob bei "WHERE a=1 AND b=2" der Index "a,b"
oder "b,a" ist.

> ... wobei neuere MySQL-Versionen auch mehrere Indizes für eine Abfrage
> verwenden können ...

Das gilt an sich aber nur bedingt. Hier sind die Regelwerke recht
kompliziert ab wann sich ein Index-Merging lohnt. Kurz und knapp kann man
sagen immer dann wenn AND Konditions soweit runtergebrochen werden können
das ein zweiter Index die Komplexität des Scans über das Teilresultset
verringert. Das hat in dem Fall aber auch viel mit der Konfiguration (Temp
Tables, Sort Buffer) zu tun.
Das obige Beispiel "WHERE a=1 AND b=2" könnte durchaus in bestimmten Fällen
(das hängt auch von der Datenverteilung ab) von zwei Indices über jeweils
"a" und "b" profitieren - aber niemals so performat sein wie ein
kombinierter Index.

> ... und wenn du eh ALLE Felder der Tabelle benötigst wäre der Index
> selber ja genauso groß wie die Tabelle ... weniger praktisch

Auch das kann man so nicht ganz stehen lassen. Durch den Index entstehen
automatisch quasi vorsortierte und durchgezählte Teiltabellen als Index.
Diese sind viel besser verzeigert als die Datentabelle und daher meist
wesentlich performater verwendbar als die Datentabelle. Es kommt gerade bei
Statistik-Tabellen sehr häufig vor das der Index am Ende um einiges größer
ist als die Nutzdaten.

> es ging ja nicht um ein simples COUNT(*), und ein COUNT(*) 
> ist auch nur
> so performant wie der Index der auf der im WHERE verwendeten Spalte
> liegt. (eventuelle JOINS außer Acht gelassen)

Wie auch meinem letzten Posting zu entnehmen ist ist gerade Count ein
hocheffektives Beispiel für den Index da hier die Anzahl de Datensätze des
Schlüssels direkt im Index gespeichert ist. Ist jemandem schonmal
aufgefallen das EXPLAIN komischweise genaue Anzahlen von Datensätzen ausgibt
die durchlaufen werden? Das kommt daher das auch der Optimizer genau diesen
Umstand nutzt und sich die Datensatzzahlen zu nutze macht um zu entscheiden
ob und wie ein Index verwendet wird.

Gruß,
Andreas


-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql