Hi Andreas,
"Wenn es separate einspaltige Indexe auf spalte1 und spalte2 gibt, versucht der Optimierer, den restriktivsten Index zu finden, indem er entscheidet, welcher Index weniger Zeilen finden wird, und diesen Index dann benutzen, um Zeilen abzurufen."
d.h. wenn ich alles eigene Indices erstelle, dann wird höchtens einer benutzt, und zwar der restriktivste, also der über b.key.
Für dieses "also" hast Du ein bißchen wenig Kontext angeboten.
Cheatahs Posting geht davon aus, daß der Index über b.wert1 und b.wert2 der restriktivste ist (und zwar von allen in Frage kommenden Indexen aller beteiligten Tabellen!), und daß deshalb von der hier berechneten kleinsten Trefferzahl ausgehend weitere Zugriffspfade auf andere Tabellen aufgebaut werden - beispielsweise über deren Index zur JOIN-Spalte, vielleicht aber auch über andere Indexe, falls entsprechende zusätzliche WHERE-Klauseln auch dort eine frühzeitige scharfe Filterung erlauben.
- Index auf b.wert1 und b.wert2
Mir stellt sich eigentlich nur noch die Frage, ob ein Index auf Spalte b.key, oder (b.wert1,b.wert2) oder (b.key,b.wert1,b.wert2). Der zweite würde vermutlich auc nicht genutzt, ich würde mal auf den 3. Tippen.
Cheatah hat ausgeführt, weshalb der zweite Index, erweitert um b.key, in diesem Fall am besten hilft - die ersten beiden Felder helfen bei der Adressierung der gesuchten Teilmenge, das dritte Feld erspart die Adressierung des Datensatzes der entsprechenden Zeile. Derselbe Index kann also innerhalb derselben Query unterschiedliche Funktionen haben.
MySQL weiß besser als ich welcher Index der beste ist, also warum sollte ich das vorschreiben?
Ob mySQL das wirklich am besten weiß, hängt davon ab, welche Informationen es auswerten darf. So detailliert habe ich keine Vorstellung vom Query Optimizer, daß ich diesem blind vertrauen würde ... aber zum Thema "regelbasierter vs. kostenbasierter Optimierer" solltest Du vermutlich mal einen Grundlagenartikel lesen, das wäre in Deinem aktuellen Stadium vermutlich hilfreich (die erforderlichen Grundbegriffe beherrschst Du inzwischen).
Ich kann Dir nur sagen, daß ich die Oracle-Möglichkeit, per "hints" die Verwendung bestimmter Indexe "nahezulegen", schon mal dringend benötigt habe, weil meine Tabelle "degenerierte" Daten enthielt (sehr viele UNIQUE-Datensätze plus einen einzigen Sonderwert, der dann aber irre oft vorkam, jedoch nie in einer WHERE-Klausel verwendet wurde), und Oracle mit seiner Anschauung des wahrscheinlichen Nutzwertes dieses Indexes total daneben lag: Die mittlere Projektivität des Index war ihm nicht gut genug, die tatsächliche (aufgrund der mir bekannten WHERE-Klauseln) war jedoch optimal. Also mußte ich Oracle zu seinem Glück zwingen ...
Und wie verrät mir EXPLAIN wie MySQL da herangeht? Ich finde EXPLAIN bis auf die Information welcher Index tatsächlich verwendet wird wenig hilfreich.
Das ist doch schon eine ganze Menge. ;-)
Außerdem zeigt Dir mySQL, wie viele Operationen es beim Zugriff auf den Index gemacht hat - es sagt Dir also seine "Kostenfunktion" in der Einheit "Indexzugriffe". Mach mal mehrere Zugriffe mit verschiedenen Suchbegriffen und laß sie Dir jeweils EXPLAINen ...
Indizes gehören zum allgemeinen Datenbankentwurf, und nicht unbedingt zur Optimierung einer Abfrage.
Sehe ich anders. Der Index ist dazu da die Anfragen zu beschleunigen, sonst nichts.
Beide Aussagen finde ich zu radikal - aber an beiden ist durchaus etwas dran.
Wird ein Index als Mittel zur Durchsetzung von Datenkonsistenz eingesetzt (also ein UNIQUE INDEX, um Duplikate innerhalb einer Spalte zu verhindern), dann gehört er in den Datenbankentwurf (letzten Endes implementiert er dabei eine CONSTRAINT, welche das RDMBS nicht mit anderen Mitteln beherrscht).
Aus diesem Blickwinkel heraus macht auch das gewohnheitsmäßige Anlegen von Primärschlüsseln Sinn - es erspart einem die in diesem Forum immer wiederkehrende Frage, wie man nachträglich Duplikate aus einer Tabelle löscht. ;-)
Zusätzliche Performance-steigernde Indizes, wie Du sie hier suchst, gehören jedoch in der Tat zur Query-Optimierung.
Du siehst, ein Schlüsselwort INDEX sagt allein noch nichts darüber aus, was man damit letzten Endes erreichen will ...
Was habe ich von vielen Indices wenn am Ende nur einer verwendet wird?
Du hast die Chance, daß in mehreren verschiedenen Situationen der Query Optimizer unterschiedliche Ausführungspläne für geeignet hält, wobei Du jeden dieser Ausführungspläne durch einen _passenden_ Index unterstützen kannst.
Bei Mehrspaltigen wird es nur kritisch ob der Index überhaupt verwendet wird, aber das muß ich nochmal nachlesen, da kommt es näämlich auf die Reihenfolge der indizierten Spalten an!
Richtig.
Viele Grüße
Michael
T'Pol: I meant no insult.
V'Lar: Of course not. You're simply speaking your mind ... as you always have.