Jan: 8-fache Laufzeit wenn 'order by' angegeben

Und das kann ja irgendwie nicht angehen ... also mach ich wohl irgendetwas falsch.

Meine Tabelle (noch'n Forum) schaut so aus:

idpost idref name

wobei idref 0 ist oder sich auf den Post bezieht, auf den Name geantwortet hat.
Ich möchte nun all die Posts erhalten, in denen Hans auf Fritz geantwortet hat.

Mein select lautet:

SELECT f_post.idpost
 FROM f_post,  f_post as t2
 where f_post.idref=t2.idpost
 and  f_post.name like 'Hans'
 and t2.name like 'Fritz'
 and f_post.idref > 0
 order by f_post.idpost desc;

Die Abfrage dauert (bei 54.000 Sätzen) laut php-myadmin 2,44 Sekunden und zeitigt 147 Ergebnisse.
Lasse ich das 'order by' weg ... bzw ersetze das 'desc' durch 'asc' dauert die gleiche Abfrage lediglich 0,315 Sekunden.

... Ich die meine 147 Sätze sortiere ich im php ja in einer 1/100.000 Sekunde ... wieso braucht mysql dafür volle zwei Sekunden?

Gruss, Jan

  1. Setze doch mal einen Index auf idpost ...

    1. Setze doch mal einen Index auf idpost ...

      Nun, ich nehme an, da wird schon einer drauf sein? idpost klingt wie ein Primärschlüssel.

      Gruss, FF

    2. Setze doch mal einen Index auf idpost ...

      Das war der richtige Hinweis. idpost ist zwar Teil des PrimaryKeys, aber eben nur ein Teil. Davor steht noch boardid.

      Definiere ich idpost nochmal extra als Index, verbessern sich die Laufzeiten erheblich.

      Allerdings verbessert sich auch die Laufzeit ohne den 'order by', so dass das seltsame Verhältnis in den Laufzeiten bestehen bleibt.

      Mit order by desc: 0,244 Seskunden
      ohne : 0,034

  2. Hi,

    ... Ich die meine 147 Sätze sortiere ich im php ja in einer 1/100.000 Sekunde ... wieso braucht mysql dafür volle zwei Sekunden?

    Solche Fragen solltest du immer zu aller erst der Datenbank selber stellen - Stichwort EXPLAIN.

    MfG ChrisB

    --
    “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
    1. Hi,

      ... Ich die meine 147 Sätze sortiere ich im php ja in einer 1/100.000 Sekunde ... wieso braucht mysql dafür volle zwei Sekunden?

      Solche Fragen solltest du immer zu aller erst der Datenbank selber stellen - Stichwort EXPLAIN.

      MfG ChrisB

      Auch kein schlechter Hinweis, ... kannte ich noch nicht ... die Sache mit dem explain.

      Zeigt folgendes

        
      id select_type table   type  possible_keys key     key_len  ref               rows   Extra  
      1 SIMPLE       f_post   ALL  NULL          NULL    NULL     NULL              54211  Using where; Using filesort  
      1 SIMPLE       t2       ref  idpost        idpost   4       DB.f_post.idref   17      Using where  
        
        
      
      

      Interpretiere ich mal so, dass MYSQL
      1. auf  f_post.name='xxxx' // Using where
      2. auf das Ergebnis filesort anwendet
      3. darauf dann t2.name='yyy' anwendet.

      Es gilt also eine Sprachkonstruktion zu finden, mit der mysql den Filesort erst auf des letzte Ergebnis anwendet und nicht schon auf das erste Zwischenergebnis anwendet.

      Was die Spalte 'rows' angeht, kapiere ich nicht wieso in der 2. Reihe '17' angegeben ist ... erhalte doch 135 Ergebnisse ... werd wohl weiter das Handbuch eifrig studieren müssen ...

      Gruss Jan.

  3. Hi,

    Die Abfrage dauert (bei 54.000 Sätzen) laut php-myadmin 2,44 Sekunden und zeitigt 147 Ergebnisse.
    Lasse ich das 'order by' weg ... bzw ersetze das 'desc' durch 'asc' dauert die gleiche Abfrage lediglich 0,315 Sekunden.

    Weil beim zweiten Versuch schon der Datenbank-Cache gefüllt ist?

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    O o ostern ...
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
    1. yo,

      Weil beim zweiten Versuch schon der Datenbank-Cache gefüllt ist?

      kann sein, muss aber nicht sein. ich könnte mir auch gut vorstellen, dass ein vorhandener index auf die Sortierspalte bei ASC für ein anderen ausführungsplan sorgt als es bei DESC er fall ist. schließlich liegt mit einem index ja schon eine reihenfolge vor.

      Ilja

  4. ich würde zunächst einen fehlenden Key verdächrigen.

    Aber auch die Formulierung like 'Hans' und like 'Fritz' ist für mich seltsam. Da du nicht mit % arbeitest, also like '%Fritz%' probiere es doch mal mit = 'Fritz'

    Keine Ahnung, wie sich ein missbrauchter like rächt.

    54.000 Sätze sind nicht so der Brüller, ich hatte in MySQL schon mit 70.000 Sätzen zu tun. Bei ordentlichen Keys kein Thema. Was ist denn deine Datenbank? Excel?

    Kalle