Du koenntest die PostingIDs direkt in SQL schreiben (mehrere auf einmal) anstelle einen Loop ueber das SQL Query zu machen, und pro ID ein Query absetzen. Ich denke, das wuerde einiges bringen, denn im Moment siehts so aus aus:
Also, MySQL hat gute Doku. Und ich bin ueberzeugt das du das schneller weisst. Ich bin von so kompliziertem Zeugs naemlich ueberfordert. Das ist was fuer Entwickler ;)
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.
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..
