Warum using filesort?
Struppi
- datenbank
Hi
ich bin grad (mysql) DB Abfragen am optimieren, jetzt hab ich aber ein Problem mit der Ausgabe von EXPLAIN
Die Abfrage ist eigentlich ganz simpel:
SELECT * FROM tabelle ORDER BY datum
datum ist ein Index
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tabelle ALL NULL NULL NULL NULL 7 Using filesort
Warum taucht hier using filesort auf?
Weil die Tabelle nur 7 Einträge hat?
Struppi.
hi,
ich bin grad (mysql) DB Abfragen am optimieren,
Vorgriff auf Vinzenz' Antwort: Welche Version?
SELECT * FROM tabelle ORDER BY datum
datum ist ein Index
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE tabelle ALL NULL NULL NULL NULL 7 Using filesortWarum taucht hier using filesort auf?
Sieht doch so aus, als ob dein Index gar nicht benutzt wird ...?
Kann ich mir aus
http://dev.mysql.com/doc/refman/4.1/en/explain.html und
http://dev.mysql.com/doc/refman/4.1/en/order-by-optimization.html
gerade auch nicht wirklich erklären - lass uns auf Godot, Verzeihung: Vinzenz, warten :-)
Weil die Tabelle nur 7 Einträge hat?
Sollte m.E. damit nichts zu tun haben.
gruß,
wahsaga
Hi,
Vorgriff auf Vinzenz' Antwort: Welche Version?
lol, genau.
http://dev.mysql.com/doc/refman/4.1/en/explain.html und
http://dev.mysql.com/doc/refman/4.1/en/order-by-optimization.html
In der Referenz zur 5er steht:
"Der Schlüssel, der zum Holen der Datensätze verwendet wird, ist nicht derselbe wie derjenige, der in der ORDER BY-Klausel verwendet wird:
SELECT * FROM t1 WHERE key2=constant ORDER BY key1;"
Könnte hier zutreffen.
Aber sonst stochere ich auch im Nebel.
MfG
Rouven
Hallo,
ich bin grad (mysql) DB Abfragen am optimieren,
Vorgriff auf Vinzenz' Antwort: Welche Version?
*g* frag' ich tatsächlich so stereotyp ... *bg*
Kann ich mir aus
gerade auch nicht wirklich erklären - lass uns auf Godot, Verzeihung: Vinzenz, warten :-)
Im Gegensatz zu Godot komme ich ...
Weil die Tabelle nur 7 Einträge hat?
Sollte m.E. damit nichts zu tun haben.
Siehe Iljas Erklärung. Überlege Dir, wieviele Zugriffe Du bei sieben Einträgen benötigst, um einen passenden zu finden. Überlege, wieviele Du bei Benutzung eines Index (was ja zusätzlicher Aufwand bedeutet) benötigst. Eine Optimierung von Sortieralgorithmen kann z.B. darin bestehen, unterhalb einer bestimmten Größe einen anderen Algorithmus zu verwenden, der ansonsten schlecht skaliert.
Freundliche Grüße
Vinzenz
yo,
Warum taucht hier using filesort auf?
Weil die Tabelle nur 7 Einträge hat?
tuning ist wohl das komplexeste thema bei datenbanken und verblüfft auch immer wieder die "fachleute", wenn sie sich einen ausfürhungsplan ausgeben lassen. deswegen gilt die goldene regel, immer alles ausprobieren.
was deine abfrage betrifft, man muss sich vor augen halten, dass ein index kein allheilmittel ist. ein index kann auch eine abfrage verlangsamen. dabei gibt es ein paar handregel, zum beispiel die erwähnte größe der tabelle von dir. bei wenigen datensätzen, macht es einfach keinen sinn, einen index zu benutzen. auch die anzahl der treffer im verhältnis zu der quelle spielt eine rolle. man sagt wenn man nicht mehr als ungefähr 10% der daten sucht, dann lohnt sich noch ein index. willst du aber 50% aller daten einer tabelle auslesen, dann wird der weg über den index eher langsamer sein. auch der inhalt der daten spielt eine rolle, die sogenannte kardinalität. wenn du also daten hast, die sich so gut wie nie unterscheiden, also entweder immer nur einträge in einer spalte ort wie berlin oder hamburg, dann wird ein b-tree index zu keinem gewünschten erfolg führen.
mysql ist nicht mein steckenpferd, aber manchmakl sind es einfach nur kleinigkeiten. bei problemen mit der performance unter oracle zum beispiel vergessen viele einfach die tabellen regelmäßig vom dbms zu analysieren, sprich das sich das dbms mal den genauen aufbau der tabelle anschaut und sich merkt. auf die informationen kann dann der optimierer zurückgreifen. aber auch da gilt, immer ausprobieren....
Ilja
was deine abfrage betrifft, man muss sich vor augen halten, dass ein index kein allheilmittel ist. ein index kann auch eine abfrage verlangsamen. dabei gibt es ein paar handregel, zum beispiel die erwähnte größe der tabelle von dir. bei wenigen datensätzen, macht es einfach keinen sinn, einen index zu benutzen. auch die anzahl der treffer im verhältnis zu der quelle spielt eine rolle. man sagt wenn man nicht mehr als ungefähr 10% der daten sucht, dann lohnt sich noch ein index. willst du aber 50% aller daten einer tabelle auslesen, dann wird der weg über den index eher langsamer sein. auch der inhalt der daten spielt eine rolle, die sogenannte kardinalität. wenn du also daten hast, die sich so gut wie nie unterscheiden, also entweder immer nur einträge in einer spalte ort wie berlin oder hamburg, dann wird ein b-tree index zu keinem gewünschten erfolg führen.
Danke für dein Ausführungen. Ich ging auch von sowas aus. Da die Abfrage von 7 Zeilen (es werden sicher nicht wesentlich mehr) auch nicht wirklich die Performance beeinträchtigen sollte.
Ich bin grad im Moment die SQL Zugriffe einer Anwendung am durchforsten und stosse immer wieder auf filesort und tmpfile. Aber ich mach es genau wie du sagst, immer wieder probieren und steige langsam dahinter.
mysql ist nicht mein steckenpferd, aber manchmakl sind es einfach nur kleinigkeiten. bei problemen mit der performance unter oracle zum beispiel vergessen viele einfach die tabellen regelmäßig vom dbms zu analysieren, sprich das sich das dbms mal den genauen aufbau der tabelle anschaut und sich merkt. auf die informationen kann dann der optimierer zurückgreifen. aber auch da gilt, immer ausprobieren....
Ja, dass hatte ich auch schon irgendwo gelesen und lasse mysql auch immer mal wieder die Tabelle analysieren, wenn ich keine andere Idee mehr habe.
Struppi.
yo,
noch ein tipp, wenn du nicht wirklich viel mehr als 7 datensätze in einer tabelle hast, dann lösch den index einfach wieder. ein objekt weniger. mit indexen wird auf dbms manchmal wie im wilden westen mit kugeln auf unschuldige indianer geschossen, sprich ohne sinn.....
Ilja
noch ein tipp, wenn du nicht wirklich viel mehr als 7 datensätze in einer tabelle hast, dann lösch den index einfach wieder. ein objekt weniger. mit indexen wird auf dbms manchmal wie im wilden westen mit kugeln auf unschuldige indianer geschossen, sprich ohne sinn.....
Klingt vernüftig.
Aber wenn ich mit der Tabelle noch JOINs durchführe, sollte der Index erhalten bleiben, oder?
Struppi.
yo,
Aber wenn ich mit der Tabelle noch JOINs durchführe, sollte der Index erhalten bleiben, oder?
der JOIN wird doch nicht über die datumsspalte geführt oder ? und selbst wenn, wäre es bei 7 Datensätze überhaupt kein problem und sollte sogar schneller gehen.
auch sollte man immer im auge behalten, dass das dbms bei einer abfrage pro tabelle nicht immer alle vorhandenen indexe nutzen kann. manche würden jetzt sagen, pro tabelle kann es bei einer abfrage nur einen index nutzen, aber diese aussage ist falsch.
Ilja
Aber wenn ich mit der Tabelle noch JOINs durchführe, sollte der Index erhalten bleiben, oder?
der JOIN wird doch nicht über die datumsspalte geführt oder ? und selbst wenn, wäre es bei 7 Datensätze überhaupt kein problem und sollte sogar schneller gehen.
Stimmt, war Quatsch - der wird auf den key durchgeführt.
auch sollte man immer im auge behalten, dass das dbms bei einer abfrage pro tabelle nicht immer alle vorhandenen indexe nutzen kann. manche würden jetzt sagen, pro tabelle kann es bei einer abfrage nur einen index nutzen, aber diese aussage ist falsch.
Jaja, wie gesagt ich bin erst so langsam am dahinter steigen wie das mit den Indizes funktioniert und wie ich die zusammenbauen kann.
Struppi.
Hallo.
deswegen gilt die goldene regel, immer alles ausprobieren.
Oder anders: Die goldene Regel lautet, dass es keine goldene Regel gibt.
MfG, at