Struppi: Warum using filesort?

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.

--
Javascript ist toll (Perl auch!)
  1. 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 filesort

    Warum 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

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. 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

      --
      -------------------
      When the only tool you've got is a hammer, all problems start to look like nails.
    2. 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

  2. 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

    1. 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.

      --
      Javascript ist toll (Perl auch!)
      1. 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

        1. 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.

          --
          Javascript ist toll (Perl auch!)
          1. 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

            1. 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.

              --
              Javascript ist toll (Perl auch!)
    2. Hallo.

      deswegen gilt die goldene regel, immer alles ausprobieren.

      Oder anders: Die goldene Regel lautet, dass es keine goldene Regel gibt.
      MfG, at