Denkfehler bei SQL-Abfrage?

[Rolf B]

Hallo Klaus1,

getrennte Indexe für logindate und username helfen bei einer Abfrage wie

SELECT username, MAX(logindate) as maxlogin 
FROM vpnprotokoll 
GROUP BY username

leider gar nichts.

Der Server könnte über den username-Index die Logtabelle indexsequenziell lesen (d.h. die Rows der Table in Indexreihenfolge verarbeiten), das ist aber nur sinnvoll, wenn es wenige Sätze sind. Andernfalls bedeutet indexsequenzielles Lesen einer Table nur, dass er kreuz und quer durch den Tablespace springen muss, und der Lesekopf der Festplatte springt mit, bis das Schmieröl kocht.

Ein kombinierter Index ermöglicht Abfragen über einen Index Scan. Zusätzliche Indexspalten bedeuten natürlich auch, dass eine Indexpage weniger Rows enthält und der Index damit größer wird. Das sequenzielle Lesen eines BTree ist aber sehr effizient, das Format ist genau dafür gemacht.

Das ist immer der Balanceakt:

• Zu wenig Indexe oder zu wenig Spalten in den Indexen - die Querys werden langsam
• Zu viele Indexe - die INSERTS werden langsam (UPDATEs auf Indexspalten natürlich auch)

Da hilft nur:

• Katalogisieren aller SQL Operationen auf einer Table
• Für jede Operation aufschreiben, wie oft sie (mutmaßlich) ausgeführt wird
• Für jede Operation einen EXPLAIN machen
• Gucken, welche Indexe überhaupt von der Engine genutzt werden
• Für jede Operation im EXPLAIN prüfen, wo Table Scans stattfinden und überlegen, ob hier ein Index helfen kann
• Unnötige Indexe vermeiden
  • ein Index auf Spalte A ist sinnlos, wenn es einen weiteren Index über die Spalten (A,B) gibt
  • ein Index, der eine seltene Query beschleunigt, ist sinnlos, wenn dadurch eine häufige Query ausgebremst wird
• Wenn es knüppeldick kommt: Trennung von operativen und dispositiven Daten. Für Auswertungen (dispositiv) braucht man oft andere Indexe als für den laufenden Betrieb (operativ), und Auswertungen müssen nicht zwingend auf dem aktuellsten Stand gefahren werden. Man kann die operative DB über Synchonisierverfahren in eine zweite, dispositive DB doppeln - z.B. einmal in der Nacht. Die dispositive DB kann andere Indexe haben, die den operativen Betrieb bremsen würden, aber für performante Auswertungen taugen. Und ein 10 Minuten SQL auf der dispositiven DB ist lange nicht so schmerzhaft wie auf der operativen DB.

Rolf