7 messages in com.mysql.lists.mysql-deRe: Performanceprobleme bei großem Jo...| From | Sent On | Attachments |
|---|---|---|
| Jens Theisen | 04 Oct 2005 13:14 | .explainselect |
| Ulf Wendel | 05 Oct 2005 00:50 | |
| Sebastian Mendel | 05 Oct 2005 01:58 | |
| Ulf Wendel | 05 Oct 2005 03:32 | |
| Jens Theisen | 06 Oct 2005 05:32 | .py |
| Jens Theisen | 06 Oct 2005 05:43 | |
| Sebastian Mendel | 06 Oct 2005 06:00 |
| Subject: | Re: Performanceprobleme bei großem Join II![]() |
|---|---|
| From: | Jens Theisen (jens...@gmx.de) |
| Date: | 10/06/2005 05:43:04 AM |
| List: | com.mysql.lists.mysql-de |
Sebastian Mendel wrote:
da muss ich erstmal Ulf zustimmen: so viele JOINS deuten immer eher erstmal auf ein Design- oder Anwendungs-Fehler hin ... :-/
Bäume sollten ohne Joins ausgelesen werden und dann in einem Array abgebildet werden, ich hab auch bisher keine Baum-Referenz-Implementierung gesehen die so viele Joins verwendet um den Baum auszulesen.
http://faq.phpbar.de/w/Baumstruktur_aus_DB_in_Array_abbilden
Deine Quelle bildet aber den Baum genauso ab wie ich. Er wird in dem Beispiel nur eben komplett ausgelesen. Ich will aber pro select nur zu einem bestimmten Knoten ueber einen bestimmten Pfad (wie in einem Filesystem). Natürlich könnte man n einzelne selects machen (wie in meinem Testprogramm ja auch getestet) anstelle von einem select mit n-1 joins.
Vermutlich kann das auch eine stored procedure machen, damit habe ich es noch nicht versucht. Eigentlich sollte es aber auch ein n-1 join tun, und für n<=32 klappt es ja auch tatsächlich (und schneller als die n einzel-selects).
Oder kannst du einen noch eleganteren Weg anbieten?
Oder der verwendete Speicher ist alle? Es wird auf Festplatte ausgelagert? Der Cache ist zu klein? [...]
Das glaube ich irgendwie nicht so recht. Schließlich ist 32 schon eine verdächtige Grenze, die Installation ist standard und ich habe es sowohl mit einem debian-386 und MySQL 4 sowie einem gentoo AMD64 MySQL 3 ausprobiert - genau das gleiche Verhalten.
Gruß,
Jens





.explainselect