Waer mal soweit vorbereitet. InnoDB initialisieren kann er nur mit nem neustart des Daemons, -> ~2-3 Minuten Downtime. Wenns euch recht ist, kann man jetzt machen, sonst mach ichs heute Abend.
# 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...
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.
Es geht darum dass bei ner Transaktion die inserts in einem rutsch gemacht werden und darum nicht für jeden einzelnen ein write lock gerupft werden muss.
So wie ich das sehe, bringt das ganze ja nur was, wenn man alle Posts als gelesen Markieren will.
Ich denke der grösste aufwand ist das Rekursive suchen der Posts oder wie seht ihr das?
Also müsste man nach lösungen suchen, wie man das beschleunigen könnte.
Werdeb Stored Procedures in MySQL 4.x schon unterstützt? Dan könnte man eine Prozedur basteln, welche die ID's ausspukt und anschliessend noch die ID's lesen.
If you are inserting many rows from the same client at the same time, use INSERT statements with multiple VALUES lists to insert several rows at a time. This is much faster (many times faster in some cases) than using separate single-row INSERT statements. If you are adding data to a non-empty table, you may tune up the bulk_insert_buffer_size variable to make it even faster. See section 5.2.3 Server System Variables.
Hast Du aber mal untersucht ob dann nicht durch InnoDB das ganze noch wurstliger wird? ich kenne keine Performancevergleichen zwischen den verschiedenen Table Typen, aber könnt ja sein..
