Помогите оптимизировать sql запрос

[MasterYan]

Помогите оптимизировать sql запрос

Значит есть такой запрос типа:

SELECT zagruzok_za_mesiac, title, id FROM table WHERE kategory_id='$id' order by zagruzok_za_mesiac DESC limit 10

он выбирает товары для нужной категории и сортерует их по количеству загрузок за месяц.
Так как товаров более 120.000 , хотелось бы оптимизировать запрос.

Выполнение этого скрипта занимает 0.24 секунды.



Подскажите как его можно еще оптимизировать?

PS: Если убрать 'order by zagruzok_za_mesiac DESC', то скрипт выполняется 0.09 секунды, но мне нужен вывод с сортировкой, будет ли рентабельно сделать сортировку с помощью массива (там обычно не более 100 наименований для каждой категории) ??

 

[findnext]

покажи explain

 

[Mr_Max]

[здесь была фигня]

 

[zerkms]

Запрос нужно не оптимизировать, а ложить в кеш.

вместо лечения болезни будем избавляться от симптомов. шикарный подход.

 

[fixxxer]

сделай индекс (zagruzok_za_mesiac,kategory_id)

 

[Mr_Max]

[и здесь была фигня]

 

[zerkms]

Mr_Max
стало не лучше. зачем оптимизировать то, что работает быстро?

 

[Mr_Max]

zerkms
Каюсь.

 

[.des.]

Автор оригинала: zerkms
вместо лечения болезни будем избавляться от симптомов. шикарный подход.

Нормальный подход, если оптимизация даст вместо 0.24 пусть даже 0.12 все равно это долго и нагрузка на базу.
При грамотном кэшировании запрос будет делаться гораздо реже, и выигрыш от оптимизации будет минимален,
зато дополнительные индексы могут замедлить кучу других вещей.

 

[zerkms]

.des.
с запросом "WHERE kategory_id='$id' order by zagruzok_za_mesiac DESC"
0.12с при 120к?
эм.... 0.12 при 120к это ненормально. это не оптимизация.

дополнительные индексы могут замедлить кучу других вещей

могут, если данные вставляются/обновляются с нереальной скоростью. товары в каталогах безусловно такие данные, которые появляются по 100тыщ штук в день, ага.
<sarcasm>

 

[MasterYan]

Автор оригинала: .des.
Нормальный подход, если оптимизация даст вместо 0.24 пусть даже 0.12 все равно это долго и нагрузка на базу.
При грамотном кэшировании запрос будет делаться гораздо реже, и выигрыш от оптимизации будет минимален,
зато дополнительные индексы могут замедлить кучу других вещей.

Кеш разумеется будет реализирован, но сейчас задача в том что б увеличить скорость оброботки запроса.

PS: 0.24 это скорость выполнения всего скрипта, 0.1683 сек время выполнения этого запроса.
Хотелось бы побыстрее

-~{}~ 06.03.09 03:50:

Поставил индексы, теперь скрипт 0.04 секунды выполняется!

ура !!!

ОРИГАТО )

 

[.des.]

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

Сколько нормально при 120к? Я вот лично не могу ответить на это абстрактный вопрос. Как бы вы не оптимизировали, при значительных нагрузках и объемах данных все равно упретесь в io.

-~{}~ 06.03.09 03:20:

Автор оригинала: MasterYan
Кеш разумеется будет реализирован, но сейчас задача в том что б увеличить скорость оброботки запроса.

PS: 0.24 это скорость выполнения всего скрипта, 0.1683 сек время выполнения этого запроса.
Хотелось бы побыстрее

-~{}~ 06.03.09 03:50:

Поставил индексы, теперь скрипт 0.04 секунды выполняется!

ура !!!

ОРИГАТО )

А вы бы все таки показали эксплайн. что в результате в плане запроса.

 

[zerkms]

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

на тот вопрос, который поставлен - это решение гораздо лучше кеширования. если не получается оптимизировать - нужно спросить почему и разобраться, а не браться за "панацею" кеширования.

Сколько нормально при 120к? Я вот лично не могу ответить на это абстрактный вопрос. Как бы вы не оптимизировали, при значительных нагрузках и объемах данных все равно упретесь в io.

io какого процесса? поиск - будет идти по индексу, который почти наверняка висит в памяти.

Поставил индексы, теперь скрипт 0.04 секунды выполняется!

выполняется 0.04 скрипт. т.е. сам запрос выполнился ещё быстрее. а теперь перематываем на http://phpclub.ru/talk/showthread.php?postid=842785#post842785 и перечитываем.
да-да, мне просто повезло.

 

[.des.]

zerkms

SELECT zagruzok_za_mesiac, title, id FROM table WHERE kategory_id='$id' order by zagruzok_za_mesiac DESC limit 10

"title" тоже возьмется из индекса?
Кэширование это не панацея это просто правильный подход и пытаться добавить кэширование, потом, когда это понадобится - ошибка и не приводит к желаемым результатам.

 

[zerkms]

Кэширование это не панацея это просто правильный подход и пытаться добавить кэширование, потом, когда это понадобится - ошибка и не приводит к желаемым результатам.

хехе ну так человек на тот момент ещё не попытался/не смог решить свою проблему - но ему уже начали давать советы на "следующий этап".

 

[.des.]

zerkms полемизировать насчет единственно верного решения начал не я.

 

[zerkms]

.des.
в данном конкретном вопросе единственно верное решение - оптимизировать запрос.