Запросы к базе
Могли ли эти 2 запроса привести к перегрузке MySQL сервера хостинга? Хостинг mchost
и
SELECT
c.*,
t.topic_title as topic_title,
t.topic_count_comment as topic_count_comment,
u.user_profile_avatar as user_profile_avatar,
u.user_profile_avatar_type as user_profile_avatar_type,
u.user_login as user_login,
b.blog_title as blog_title,
b.blog_type as blog_type,
b.blog_url as blog_url,
u_owner.user_login as blog_owner_login
FROM
prefix_topic_comment_online as co
JOIN prefix_topic_comment AS c ON co.comment_id=c.comment_id
JOIN prefix_topic AS t ON co.topic_id=t.topic_id
JOIN prefix_user AS u ON c.user_id=u.user_id
JOIN prefix_blog AS b ON t.blog_id=b.blog_id
JOIN prefix_user AS u_owner ON b.user_owner_id=u_owner.user_id
ORDER by co.comment_online_id desc limit N, N
и
SELECT
t_fast.*,
tc.*,
u.user_login as user_login,
IF(tv.topic_id IS NULL,N,N) as user_is_vote,
tv.vote_delta as user_vote_delta,
IF(tqv.topic_id IS NULL,N,N) as user_question_is_vote,
bu.is_moderator as user_is_blog_moderator,
bu.is_administrator as user_is_blog_administrator,
IF(tr.comment_count_last IS NULL,t_fast.topic_count_comment,t_fast.topic_count_comment-tr.comment_count_last) as count_comment_new,
IF(ft.topic_id IS NULL,N,N) as topic_is_favourite
FROM (
SELECT
t.*,
b.blog_title as blog_title,
b.blog_type as blog_type,
b.blog_url as blog_url,
b.user_owner_id as blog_owner_id
FROM
prefix_topic as t,
prefix_blog as b
WHERE
N=N
AND t.topic_publish = N AND ( t.topic_rating >= N or topic_publish_index=N ) AND b.blog_type in ('S','S')
AND
t.blog_id=b.blog_id
ORDER by t.topic_date_add desc
LIMIT N, N
) as t_fast
JOIN prefix_user AS u ON t_fast.user_id=u.user_id
LEFT JOIN (
SELECT
topic_id,
vote_delta
FROM prefix_topic_vote
WHERE user_voter_id = -N
) AS tv ON t_fast.topic_id=tv.topic_id
LEFT JOIN (
SELECT
topic_id
FROM prefix_favourite_topic
WHERE user_id = -N
) AS ft ON t_fast.topic_id=ft.topic_id
LEFT JOIN (
SELECT
topic_id,
comment_count_last
FROM prefix_topic_read
WHERE user_id = -N
) AS tr ON t_fast.topic_id=tr.topic_id
LEFT JOIN (
SELECT
topic_id
FROM prefix_topic_question_vote
WHERE user_voter_id = -N
) AS tqv ON t_fast.topic_id=tqv.topic_id
LEFT JOIN (
SELECT
is_moderator,
is_administrator,
blog_id
FROM prefix_blog_user
WHERE user_id = -N
) AS bu ON t_fast.blog_id=bu.blog_id
JOIN prefix_topic_content AS tc ON t_fast.topic_id=tc.topic_id
order by t_fast.topic_date_add desc
58 комментариев
— подключить мемкешь или увеличить память для мемкеша
— другой тарифный план,
— покопать — переделать запросы
Вопрос именно в такой форме, потому-что у меня есть сомнения в правдивости перегрузки сервера. Возможно просто хотят впарить тариф по-дороже.
да… хостеры, сцуки, такие
Я отмечу, что узкое место в любой веб архитектуре — это субд.
Нельзя сделать «классную» архитектуру с ужасными запросами.
субд — горлышко для архитектур ;)
это же тоже в сумме немного грузит машину или нет?
Такие запросы обязательно надо кешировать и только.
Посмотрите сами. Каждый join или каждый подзапрос — это фактически запрос.
Плюс ко всему order by и limit (1)
При «приличном» кол-ве записей в таблицах — эти запросы при нагрузке поставят сервер в ступор.
Выход только один — переписать архитектуру, что невозможно.
Установить на свой сервер сайт и правильно настроить кеширование. Я думаю memcached вас спасет.
А запросы и правда ужасные, особенно left join (select…
Это честно говоря ужас на нагруженных проектах. Советую автору архитектуры пересмотреть и оптимизировать запросы.
В любом случае мы будем этим заниматься и если что переписывать запросы. Там кстати в маппере для топиков уже есть первые попытки оптимизации. Но детальнее можно сказать только после профилировки. Правда я не силен в этом вопросе. Этим будет заниматься отдельный человек. Думаю, он здесь скоро объявится.
Понимаю, много вопросов. Можно личным письмом если не хотите публично рассказывать.
А сколько записей в базе?
На сильно нагруженные проекты можно забить.
Не думаю что с таким запросом можно нормально работать — это просто ужас.
Это япривел только один такой запрос, там если пройтись — то будет ужас еще больше.
А вот его EXPLAIN — это пиздец (другого слова я не подобрал)
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
6 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
5 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
4 DERIVED prefix_topic_read ref user_id user_id 4 1 Using where
3 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
2 DERIVED NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
З.Ы. на смену архитектуры не посылать (конкретное предложение ожидается).
Это хороший кусок работы. Рефакторинг запросов, подразумевает под собой косметические изменения архитектуры.
Работы там хватит с головой.
Если вы профи, тогда возможно вы бы могли помочь проекту за вознаграждение? (Если конечно, Ort не будет против)
этот запрос идёт на не авторизованного юзера, поэтому везде стоит согласен, что их можно вообще убрать из запроса, но такие подзапросы выполняются очень быстро, т.к. идут по ключу. В join'ах я вижу только один минус — не возможность кешировать их отдельно от главного запроса. В остальном, что отдельный запрос, что равноценный join. А вообще вот тут писал, что планирую сделать с запросами
Нужно менять архитектуру, причем полностью, а автору совет, более детально изучить оптимизации MySQL, а не делать упор на архитектуру php ;)
Узкое место (горлышко) в нагруженных проектах — не php код, а СУБД. Пора это знать.
Они очень хорошо описывают работу оптимизаторов и т.п. Если проблем с анг. языком нет — через неделю вы будите почти асом в оптимизациях, а после реальных тестов, где-то через пару месяцев — гуру ;)
ссылка такая:
ниже уже отписали
отличная книга по оптимизации для Mysql
High Performance MySQL, Second Edition
в формате pdf просто находится через google
очень советую к прочтению.
Возьмите для начала все свои запросы explain-ом проверьте ;)
Я уже вверху писал, как можно сделать запрос не использующий совсем индексы?
Вы мне ответите? Это работа? Это знание узкого места? Я наверно резковато, но я знаю о чем говорю. Разработчику главнее конструктивная критика а не дифирамбы…
Вторую часть вашего коммента вообще не понял…
От вас пока услышал, что БД это самое узкое место. Но это и так все знают. Возможно у вас есть конкретное предложение?
Я привел explain запроса. Запрос не брал совсем индексов, это правильно? ;)
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
6 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
5 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
4 DERIVED prefix_topic_read ref user_id user_id 4 1 Using where
3 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
2 DERIVED NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const table…
при авторизованном они как раз и нужны, а при госте от них можно и избавиться, но я этого не сделал, т.к. при user_id=-1 они выполняются мгновенно
а вот explain этого запроса!
Вы мне ответьте, а «где» индексы !?
Причем не использующих индексов. Надеимся на кеш ;)?
C такими запросами можно только альфу выпускать
индексы есть. Меня только смущает полей key = null при possible_key = blog_id,topic_rating,topic_publish
Оптимизатор пытался выискать оптимальный индекс, но не один не попал под условия выборки, значит запрос составлен неверно или индекс. :\
Да и посмотрите на derived там тоже null :\
Наследованная таблица select — null индекс :\
в двух словах
Это один тормоз + шанс потеряться оптимизатору.
Вы все делаете для того чтобы оптимизатор послал вас очень далеко и перебирал всю таблицу
его можно попробовать разбить на два через UNION, для того чтоб задействовать ключи topic_rating и topic_publish_index по отдельности, и избавиться от OR