[BIT]

Есть умельцы, работающие с SQL, умеющие не просто делать запросы вида SELECT,DELETE...
А способные разобраться в запросах вида:

SELECT forum.forumid as forumid, thread.threadid as threadid, post.parentid as postid
FROM _wwwpost AS post
INNER JOIN _wwwthread AS thread ON ( thread.threadid = post.threadid )
LEFT JOIN _wwwthreadread AS threadread ON ( threadread.threadid = thread.threadid
AND threadread.userid = 12911)
INNER JOIN _wwwforum AS forum ON ( forum.forumid = thread.forumid )
LEFT JOIN _wwwforumread AS forumread ON ( forumread.forumid = forum.forumid
AND forumread.userid = 12911)
WHERE thread.lastpost > IF(threadread.readtime IS NULL , UNIX_TIMESTAMP() - (10*86400 ) , threadread.readtime)
AND thread.lastpost > IF(forumread.readtime IS NULL , UNIX_TIMESTAMP() - (10*86400 ) , forumread.readtime)
AND thread.visible IN (0,1,2)
AND thread.sticky IN (0,1)
AND post.dateline > IF(threadread.readtime IS NULL , UNIX_TIMESTAMP() - (10*86400 ) , threadread.readtime)
AND post.dateline > IF(forumread.readtime IS NULL , UNIX_TIMESTAMP() - (10*86400 ) , forumread.readtime);

найти слабые места запроса(которые не используют индексы так, как хотелось бы)
Если есть желание попробовать свои знания на загруженном сервере(>13 000 000 запросов в день), буду рад познакомиться с таким человеком.

[BIT]

опять тишина )))

[Seefon]

Ты Лучше бы на Ксист отписал. Тут некоторые Венду поставить не могут, а ты уж про MySQL...

[BIT]

Буду верить в лучшее... да и сам доизучу индексы тогда...

[tramway]

так а где индексы-то?

Я MySQL не знаю, но возможно есть опция посмотреть не результат запроса, а так называемый PLAN, там написан весь порядок - что перебираем, с чем джойним по какому индексу, как отбираем... перебор без индекса напишет типа raw что-нибудь. Индексы бывают разные, в оптимизированной базе одно поле может быть в нескольких индексах, нужно выбирать по юникам/фильтрам/статистике.
13М запросов лучше вообще без SQL делать, а на прямых ссылках, тогда хоть триллион т.к. она вообще ничего не ищет т.к. ничего не теряет.

Нужно знать сами индексы, структуру базы, ее наполнение, статистику значений, повадки оптимизатора. В MySQ эти IF скорее всего оптимизатору не понятны и будут перебираться все записи, лучше

AND post.dateline > IF(threadread.readtime IS NULL , UNIX_TIMESTAMP() - (10*86400 ) , threadread.readtime)

расписать

AND (threadread.readtime IS NULL AND post.dateline > UNIX_TIMESTAMP() - (10*86400 )
OR post.dateline>threadread.readtime) - скобки расставь
тогда если null'ы проиндексированы и оптимизатор разбирает такие выражения, он всего два раза выполнит бинарный поиск, ну а что нужно перебирать его придется перебирать.

поищи слово PLAN в документации

Если база маленькая анализ запроса может выполняться дольше чем сам запрос. Тут куча нюансов, вообще DBA целая профессия, причем нужно знать конкретные сервер-базу-запросы, а не теории. И все равно иногда запросы летают, а добавили одну запись, дурной оптимизатор запросов подсуетился и запрос зависает на сутки.