nicht angemeldet
Jede gute Datenbank kennt Regeln zur Optimierung. Dazu ist dann allerdings schon wieder Verständnis für die Speicherungs - und Zugriffsmethoden der Datenbank nötig.
Hm ... *eigentlich* sollte das ja der Optimizer machen.
Man kann eine Wissenschaft daraus machen. Das geht hier aber denke ich zu weit. Zumal dies dann auch andere Anwendungen betrifft, die ebenfalls auf die Tabellen zugreifen.
Genau. Schon in Oracle 7 hatte das Kapitel "The Optimizer" im "Server Concepts"-Handbuch 65 Seiten ...
Die Konzepte für performance tuning, die mir inzwischen noch eingefallen sind, sind:
a) Ausführungpläne ansehen - Oracle kann in einem trace modus jede Transaktion protokollieren und zeigen, welche Tabellenzugriffe als full table scan und welche über welche Indexe erfolgen. Da sieht man dann, was er wirklich tut.
b) "hints" - bei Oracle kann man in einer speziellen Syntax in die SELECT-Anweisungen hineinschreiben, wie sie ausgeführt werden soll (also 3GL-Denken). Dabei kann man festlegen, wo full table scans und wo Indexzugriffe erfolgen sollen und anderes mehr.
c) Vektorielle Ergebnispuffer - ein "fetch" holt nicht nur einen Treffer, sondern gleich ein paar tausend (wenn man genügend RAM übrig hat).
Das hat mir mal ein Programm, welches eine Tabelle mit 15 Mio. Datensätzen nahezu linear verarbeitet, um Faktor 6 beschleunigt, bloß weil jetzt nicht mehr 15 Mio "fetch" erfolgten, sondern nur noch 15000 ...
Daß die Reihenfolge der from-Angaben die Reihenfolge der Joins beeinflussen kann, hat Kess schon erwähnt - dies in Verbindung mit den Ausführungsplänen erlaubt es, tatsächlich einen komplexen Join handzuoptimieren, auch schon ohne (proprietäre) "hints".
Wenn ich jetzt noch wüßte, ob *irgendwas* davon in mySQL existiert ...
Und weil man das Naheliegende ja gerne übersieht: Was für Indexe hast Du denn auf Deinen Tabellen?
Wer so tief in die Materie einsteigt, sollte sich dann besser gleich eine 'gescheite' (nicht hauen bitte) Datenbank zulegen. ;-)
Meine Rede seit '33 ... :-)