Das
MySQL noch nicht einmal einfachste Optimierungen hinbekommt (hier über generische Indexstatistiken, ein 10-Zeiler), ist ein weiteres Argument für andere RDBMS, z.B. Firebird (die offenbar bevorzugte
DB des Threadstartes).
Konstrukte, die Tabellen verknüpfen und so aussehen, sind zu vermeiden:
select * from a,b where a.id = b.id
.
Besser ist die Verwendung eines JOINS
select * from a join b on a.id = b.id
Neben den üblichen Fallstricken, über die man bei komplexeren Queries stolpert, wenn man die bequeme Komma-Schreibweise benutzt, ist es auch organisatorisch sinnvoller, zwischen
Verknüpfungs- und
Filterbedingungen zu trennen.
Anstatt also:
select * from a,b,c where a.id = b.id and a.user = 5 and a.xid = c.xid
zu schreiben, wäre hier ein
SQL-Code:
select *
from a
join b on a.id = b.id
join c on a.xis = c.xid
where a.user = 5
besser.
Speziell bei sehr komplexen Queries verliert man sonst den Überblick. Ein
Query-Optimizer kann eine Where-Klausel, die wirklich nur filtert, auch wesentlich besser optimieren, da die Verknüpfungsbedingungen bereits in den JOINs verwurstet sind (und i.a. eh auf PKs aufsetzen). Man sollte auch nicht vergessen, das der Optimizer durch alle Kombinationen der Where-Klausel durchprobiert (einige machen das zumindest).
@alcaeus: Wenn ihr ein
besseresanderes RDBMS genommen hättet, würdet ihr nicht so viel Zeit mit
Query-Optimierungen verbraten.
Andere DBs machen eure Handoptimierungen automatisch.
MSSQL z.B. ignoriert ein ORDER BY (bzw. verbrät 0.0 ms Zeit), wenn die Sortierspalten über einen 'Clustered Index' indexiert sind, denn dann stimmt die Reihenfolge der Datensätze schon. Also kann man getrost sortieren und nur den obersten Datensatz nehmen.
Dessenungeachtet ist deine/eure Lösung aber eh besser, weil es eine Anforderung ('zeig mir den letzten...') integral im
DB-Design verankert und nicht versucht, über RDBMS-spezifische Features hier ein schnelles Ergebnis zu bekommen: Euer
DB-Design wird auch auf einem anderen RDBMS performant ablaufen.