SELECT T.*, U.`avatar`, U.`login`, B.`name` AS `blog_name`, B.`sname` AS `blog_sname`, F.`id` AS `favourite`, R.`id` as `rated`, BM.`id` AS `moderator`, PV.`answer_id`
FROM `live-cs_topics`AS T
JOIN `live-cs_blogs` AS B
ON B.`id`=T.`parent_id`
LEFT JOIN `live-cs_users` AS U
ON T.`author`=U.`id`
LEFT JOIN `live-cs_blogs-moders` AS BM
ON BM.`blog_id`=B.`id` AND BM.`user_id`=1
LEFT JOIN `live-cs_topics-fav` AS F
ON F.`topic_id`=T.`id` AND F.`user_id`=1
LEFT JOIN `live-cs_topics-rating` AS R
ON R.`topic_id`=T.`id` AND R.`user_id`=1
LEFT JOIN `live-cs_poll-votes` AS PV
ON PV.`poll_id`=T.`id` AND PV.`user_id`=1
WHERE T.`deleted`='0'
ORDER BY T.`date` DESC
LIMIT 0, 10
он отрабатывает за 1-1.5 секунды, там 10 000 записей
такой же запрос, но с доп. условиями, лимит по дате — отрабатывает за 0.003
explain:
+—-+————-+——-+——–+——————————-+————-+———+—————————+——+———————————+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+——————————-+————-+———+—————————+——+———————————+
| 1 | SIMPLE | B | ALL | PRIMARY | NULL | NULL | NULL | 21 | Using temporary; Using filesort |
| 1 | SIMPLE | T | ref | parent_id,deleted,parent_id_2 | parent_id_2 | 4 | live-cs.B.id | 264 | Using where |
| 1 | SIMPLE | U | eq_ref | PRIMARY | PRIMARY | 4 | live-cs.T.author | 1 | |
| 1 | SIMPLE | BM | eq_ref | blog_id | blog_id | 8 | live-cs.T.parent_id,const | 1 | Using index |
| 1 | SIMPLE | F | eq_ref | user_id | user_id | 8 | const,live-cs.T.id | 1 | Using index |
| 1 | SIMPLE | R | eq_ref | user_id | user_id | 8 | const,live-cs.T.id | 1 | Using index |
| 1 | SIMPLE | PV | eq_ref | poll_id | poll_id | 8 | live-cs.T.id,const | 1 | |
+—-+————-+——-+——–+——————————-+————-+———+—————————+——+———————————+
сама страница для наглядности — http://live-cs.ru/topic/
т.е. выводятся все топики, с постраничной разбивкой
сам COUNT считает за 0.004, видимо тормоза в джоинах, т.к. тут юзается единственный индекс при выборке — deleted и date при сортировке
но все джоины идут по id с primary индексами
как отсечь тормоза?