- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
(
SELECT SQL_CALC_FOUND_ROWS attach, blog.blogid, blog.dateline, blog.rating
,blog.blogid AS blogid_order, blog.dateline AS dateline_order, blog.rating AS rating_order
FROM vbul_blog AS blog
LEFT JOIN vbul_userlist AS buddy ON (buddy.userid = blog.userid AND buddy.relationid = 218376 AND buddy.type = 'buddy')
LEFT JOIN vbul_userlist AS ignored ON (ignored.userid = blog.userid AND ignored.relationid = 218376 AND ignored.type = 'ignore')
LEFT JOIN vbul_blog_user AS blog_user ON (blog_user.bloguserid = blog.userid)
WHERE ((options_ignore & 1 AND ignored.relationid IS NOT NULL) OR (options_buddy & 1 AND buddy.relationid IS NOT NULL) OR (options_member & 1 AND (options_buddy & 1 OR buddy.relationid IS NULL) AND (options_ignore & 1 OR ignored.relationid IS NULL))) AND (~blog.options & 8
OR
(options_buddy & 1 AND buddy.relationid IS NOT NULL))
AND state IN('visible') AND blog.pending = 0 AND blog.dateline <= 1346700322
) UNION (
SELECT attach, blog.blogid, blog.dateline, rating,
blog.blogid AS blogid_order, blog.dateline AS dateline_order, blog.rating AS rating_order
FROM vbul_blog AS blog
WHERE blog.userid IN (218376)
)
ORDER BY dateline_order DESC
LIMIT 0, 5;
Сей чудесный запрос притаился где-то в недрах форума vbulletin
Follow us!
Он вешает мой сервер на 16 ядер и 32 гига ОЗУ.
Не работал конкретно с vbulletin, но vbul_blog скорей всего не бывает без соответствующей строки в vbul_blog_user. Поменяй для этого джоина LEFT на INNER, убедись что есть индекс на bloguserid/userid есть, и поставь этот джоин перед остальными. У LEFT-ов в мускуле есть такая непонятная фича - они не пользуются индексами...
Ещё иногда дополнительно помогает перенос условий, относящихся к основной таблице в ON первого же INNER JOIN-а - получается такой себе фильтр перед попыткой джоинить остальное месиво. Но тут уж надо подоробнее с кодом разбираться, как этот condition строится. :)
А вообще надо смотреть внимательно на структуру таблиц. Иногда пара ключей превращают 2 минуты раздумий в 100-200 мс.
А по поводу вопроса - да, отменяет. Говно либо в структуре базы, либо в коде, который генерит этот запрос. Но не в самом запросе.
P.S. А ещё скажи спасибо что LIMIT 0,5, а не, скажем LIMIT 100500,5 - он бы тогда не то, что повесился... Он бы тогда сконструировал мега-систему, чтоб когда дёрнется верёвка на его шее - его ещё пристрелило, вылило ведро кипящей смолы, утопило, и взорвало. :)
И если бы это был единственный пример некомпетентности разработчиков данного форума в плате оптимизации структуры БД и запросов, так нет, мне каждую неделю по 1-2 запроса приходится переделывать.
А то тебе теперь хоть std:: добавляй.
На веки ваш QLispGovno.