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