1 up | 2 up | 3 up | 4 up | 5 up | 6 up | 7 up | 8 up | 9 up | 10 up | 11 up |
^^^ Additional posts ^^^
zorg.ch
#31387 by @ 05.05.2004 14:25 - nach oben -
merci, ich schau den mal an...
zorg.ch
#31417 by @ 05.05.2004 21:04 - nach oben -

mysql$ explain SELECT user.clan_tag, user.username, c2.*, UNIX_TIMESTAMP(c1.date) as date, count(c1.id) as replies from comments as c2
->
-> left join comments as c1 on c1.id = c2.thread_id and c1.board = c2.board
->
-> left join user on c2.user_id = user.id group by c1.thread_id order by lastpost desc limit 0,23;
+-------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
+-------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
| c2 | ALL | NULL | NULL | NULL | NULL | 31042 | Using temporary; Using filesort |
| c1 | eq_ref | PRIMARY,board | PRIMARY | 4 | c2.thread_id | 1 | |
| user | eq_ref | PRIMARY | PRIMARY | 4 | c2.user_id | 1 | |
+-------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
3 rows in set (0.00 sec)

zorg.ch
#31481 by @ 06.05.2004 15:31 - nach oben -
das heisst dass er für c2 keinen Index hat?
da müsste ich so einen machen: (thread_id, board) ?
zorg.ch
#31487 by @ 06.05.2004 15:59 - nach oben -
Er macht, on disk (in /tmp, um genau zu sein) eine temporaere Tabelle. Kopiert den *GESAMTEN* Inhalt der comments Table da rein. Macht dann einen Fulltable-Scan auf diese temporaere Tabelle, und gibt irgendwann dann mal ein Resultat aus.

/tmp ist gluecklicherweise seit langem schon eine Ramdisk, sonst wuerde ein Query *wesentlich* laenger als ne Sekunde dauern.

Ich versteh allerdings nicht wirklich was du mit diesem Query erreichen willst, allerdings fuehrt er das nach Query-Log pro Pagehit aus ;)
zorg.ch
#31492 by @ 06.05.2004 16:22 - nach oben -
Weiss nicht mehr genau... ich glaube das mach ich, damit ich die Threads in der Forum-Übersicht nach deren Lastposts sortieren kann.
zorg.ch
#31496 by @ 06.05.2004 17:07 - nach oben -
Ich koennte die table mal kopieren, und schauen wie man das schneller machen kann.
zorg.ch
#31503 by @ 06.05.2004 19:02 - nach oben -
Dass er ne temp table macht scheint logisch... die Tabelle comments kommt 2x drin vor...
aber den filesort check ich nicht...
Hab jetzt nämlich 2 indexes gemacht: thread_id, board, lastpost und id, board, lastpost...
zorg.ch
#31504 by @ 06.05.2004 19:12 - nach oben -
Eine Temp Table hat logischerweise nie Indizes.

Das ist das, was ich mal hervorgebracht habe. Zusaetzliche Indizes bringen bei den Queries ueberhaupt nichts (Primary key id reicht fuer die ON statements). Das SQL_SMALL_RESULT fuehrt dazu, das temp tables im memory verwendet werden. Das bringt immerhin 0.25s (Also 1.5s statt 1.75s).

SELECT SQL_SMALL_RESULT
user.clan_tag,
user.username,
c2.*,
UNIX_TIMESTAMP(c1.date) AS date,
count(c1.id) AS replies
--
FROM comments AS c2
--
LEFT JOIN
comments AS c1 ON

c1.id = c2.thread_id
AND c1.board = c2.board
--
LEFT JOIN
user ON

c2.user_id = user.id
--
GROUP BY c1.thread_id
--
ORDER BY lastpost DESC
--
LIMIT 0,23;
zorg.ch
#31505 by @ 06.05.2004 19:35 - nach oben -
Ich könnte natürlich auch statt der Relation 23x ne Query machen mit Index. Vielleicht wärs ja schneller? Früher hatten wirs so...

Wenn diese Query die grosse Wüstheit ist, könnte man natürlich auch numreplies und die lastpost id in dem thread-record abspeichern.
zorg.ch
#31506 by @ 06.05.2004 19:41 - nach oben -
Es ist einfach das, was es ab und zu in den slow-query log schafft (queries laenger 2s).

Waers nicht gescheiter wenn du ne table fuer threads (so als eine art index table, mit titel, lastpost titel/user) etc. haettest?
zorg.ch
#31507 by @ 06.05.2004 19:45 - nach oben -
Wäre auf die Länge wohl gescheiter...