1 up | 2 up | 3 up | 4 up | 5 up | 6 up | 7 up | 8 up | 9 up | 10 up | 11 up | 12 up | 13 up | 14 up | 15 up |
^^^ Additional posts ^^^
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...