8-fache Laufzeit wenn 'order by' angegeben
Jan
- datenbank
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
Setze doch mal einen Index auf idpost ...
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
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
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
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.
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
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
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