# User@Host: zooomclan[zooomclan] @ localhost []
# Query_time: 18 Lock_time: 0 Rows_sent: 23 Rows_examined: 94517
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;
Dieses Query ist nicht indexed, d.h. er macht einen full table scan.
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;
Com_replace und Com_update werden von UPDATE Statements ausgelloest. Da gibts irgendwelche Unterschiede. Com_select sind SELECT Statements, welche *NICHT* vom Query Cache behandelt wurden. Qcache inserts sind Querys die in den Qcache kamen, Qcache queries in cache ist die Anzahl Queries die derzeit im Query Cache sind.
Man sieht also, das sehr viel in die DB geschrieben wird, was dann natuerlich den Querycache ungueltig macht. Qcache hits sind die anzahl Queries die aus dem Cache beantwortet wurden. 170000/340000, also knapp die Haelfte. Das ist ja schonmal nicht schlecht. Slow queries sind Queries die laenger als 2s gedauert haben. Sort_scan ist die Anzahl full table scans -> Queries die keine Indices benutzen.
