оптимизация

Добрый всем день

есть такой запрос

проследи чтобы в таблицах было индексы
и count лучше ставить индексное поле всесто *

adrub на это поле индекс поставь

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Спасибо, индексы уже где нужно проставлены. Заменил * на индексируемое поле как вы посоветовали. Сразу же протестировал, стало быстрей.

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

count по индексу читает быстро - хjтя это тупой оптиvизатор в mysql он должен был сам сообразить взять primary key

astatus здесь индекс попробуй поставить

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Спасибо за ответы ) В принципе производительность хорошая, просто думал что можно еще лучше сделать!

а разве ему нужен не индекс по двум полям? Мы же говорим про MySQL, не правда ли?

тогда уж (adrub, astatus)
А explain и ddl таблиц не помешал бы.

Лучше всего иметь индексы по astatus, adrub и apremium (скорее всего отдельные)
И вытягивать все count(*) отдельными запросами. count(*) при наличии индексов сработает быстрее, чем count(выражение).

Плюс select count(*) from tbl where f > 0
иногда бывает полезно заменить на (select count(*) from tbl) - (select count(*) from tbl where f = 0 ), если f в таблице не имеет отрицательных значений, а нулей мало.

В любом случае нужно на конкретной вашей базе попробовать все варианты и выбрать наилучший.

эм, с чего бы это? у него
1) последовательность запроса именно astatus, abrub;
2) подзапрос имеет WHERE astatus > 0;
как при этом получается индекс (adrub, astatus) ?
почитаю ка про оптимизатор мускулевый)

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

(Отредактировано автором: 24 Сентября, 2011 - 21:50:43)

можно посмотреть план запроса
и вобщем то даже задать его
но то что нужен отдельный индекс по полю astatus вместо индекса по двум полям - это очевидно и так

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Потому что adrub - константа. Так как ключ упорядочен по значениям, запрос отсечёт моментально всё, не равное константе и останется только смотреть малый объём второй части ключа.
Иначе - придётся сначала искать все astatus>0 и в каждом искать adrub = константа.


Смотрит и меняет всегда. Ещё на этапе разбора синтаксиса - хотя бы удостовериться, что запрос вообще имеет смысл, как то limit 0, where `a`=1 and `a`=2 и более хитрые варианты.

-----
PostgreSQL DBA