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 ;)
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...
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;