7 ноября 2013 в 19:56
Доброго времени суток!
Нужен дельный совет. При помощи Views создается запрос, но время его выполнения несколько велико.
Первая загрузка - тут все плохо((
Executed 350 queries in 823.4 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 1367.98 ms.
FROM node node
INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
LEFT JOIN content_type_photo_post node_data_field_urgently ON node.vid = node_data_field_urgently.vid
WHERE (
node.status =1
)
AND (
node.type
IN (
'video', 'text', 'photo'
)
)
ORDER BY node_sticky DESC , node_created DESC
LIMIT 0 , 6
По phpmyadmin: Отображает строки 0 - 5 ( 6 всего, Запрос занял 0.7448 сек.)
повторное обновление(этого запроса нет):
Executed 330 queries in 30.42 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 494.06 ms.
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE node ref PRIMARY,node_status_type,node_type node_status_type 4 const 23054 Using where; Using temporary; Using filesort
1 SIMPLE node_comment_statistics eq_ref PRIMARY PRIMARY 4 *.node.nid 1
1 SIMPLE node_data_field_urgently eq_ref PRIMARY PRIMARY 4 *.node.vid 1
куда стоит копать?
Комментарии
при повторном обновлении Вы ловите кеш, отсюда такая разница.
Что-то я не разглядел узких мест в запросе, либо я слепой, либо что-то не так с сервером.
(вообще там самое тяжелое это DISTINCT, однако он обычно даже на целероне работает быстрее)
вопрос не про кеш. более 300 запросов выполняются за 20мс., а этот запрос почти секунда. Отсюда вопрос, можно это время уменьшить конфигурацией mysql или нужно копать в сторону индексов?
а смысл? что бы это сработало, необходимо, что бы node.type, node.status, node.created, node.sticky были единым ключом, кроме того, проблему это не решит(хотя, возможно, чуть чуть ускорит), словом, весьма сомнительное действие.
для начала попробуйте выполнить этот запрос без сортировки, мне кажется проблема именно в ней(либо её сочетании с чем-то, например, DISTINCT).
Узким местом могут быть временные таблицы, используемые для DISTINCT, либо слишком мелкий размер буфера для сортировки(при заполнении буфера данные скидываются на жесткий диск - слишком маленький буфер = 100500 операций с диском для одной сортировки), та же ерунда с буфером строк уже на возврате, однако, последние 2 пункта маловероятны ввиду использования LIMIT в запросе, который должен был прекратить все это безобразие сразу, как будет найдено 6 строк.
Но в любом случае, этот запрос должен выполняться быстро даже на допотопном железе с дефолтными настройками, копайте в сторону настроек БД.
Еще можно нанять RxB, он все сделает
с дефолтными еще не пробовал, но конфиг mysql подкрутили, теперь время уменьшилось раза в 4-5
RxB на предохранителе;) может понадобится аудит провести, как-нибудь
Что сразу RxB? RxB не панацея
Добавьте составной индекс:
type, status, sticky, created
Тормозит, потому что сортировка не использует индекс