|
Задавайте вопросы, мы ответим
Вы не зашли.
Как-то на практике замечал, что GROUP BY работает быстрее, чем DISTINCT, но всё же такие запросы достаточно медленны. Можно ли как-то ускорить их? Я так понимаю, что индексы они не используют, или только у меня не используют 
Подскажите плз выход.
Неактивен
DISTINCT, согласно описанию, выполняет неявный GROUP BY. Отличие в производительности может быть, но объяснить его рационально сложно. Индексы использует, но нужны правильные составные индексы, так как GROUP BY выполняется после WHERE. Поясню примером:
SELECT * from x WHERE y=10 GROUP BY z;
Требует индекс KEY(y,z)
Если индекса нет правильного, а есть только KEY(z), то использовать его не имеет смысла, так как придется накладывать на него условие y=10, а это в лучшем случае MERGE индексов, а в худшем, перебор таблицы.
Неактивен
А если в условии WHERE используется несколько полей, то индекса KEY(y,z) будет достаточно, если условие y=10 будет на первом месте? Или же нужен составной индекс на все поля?
Я так понимаю, что поле группировки в составном индексе должно быть последним?
Неактивен
Запрос:
SELECT * from x WHERE y1=10 AND y2=10 GROUP BY z;
Требует индекс KEY(y1,y2,z)
Идея в том, чтобы использовать только один ключ, если его использование обрывается в последовательности операций, выполняемых MySQL, то далее без ключей
Еще есть тема про составные индексы: http://sqlinfo.ru/forum/viewtopic.php?id=151
Кроме того, условие типа > или < обычно является последним, использующим индекс
Неактивен
Не совсем понял
Если у меня условие идёт по 10 полям, а группировка по одиннадцатому, которое не участвует в условии, для использования индекса при группировке нужен индекс на все 11 полей?
Неактивен
Именно так. MySQL сначала накладывает WHERE, затем группирует. Индекс может использоваться только один (за редким исключением ситуаций с MERGE индексов), соответственно последовательность в нем должна соответствовать последовательности использования - сначала 10 полей WHERE, затем 1 поле GROUP BY. Использование индекса остановится, если среди WHERE есть условия < или >
Неактивен
Вот использование < и > тоже интересно... Получается, при их использовании, значения не берутся из индекса и ускорить выборку уже никак нельзя?
В моих запросах есть и <, и >, и группировка. Значит, как я понимаю, включение поля группировки в использующийся индекс не имеет смысла?
Также, получается, что нет смысла включать в индекс поля, которые ищутся по условиям < и/или >? И тем более если таких полей несколько
Неактивен
Вот, к примеру, поле даты. Нужно найти записи, удовлетворяющие диапазону дат. Используем `date`>='date1' AND `date`<='date2'. Значит поле `date` не имеет смысла включать в индекс?
Неактивен
Neval написал:
Вот, к примеру, поле даты. Нужно найти записи, удовлетворяющие диапазону дат. Используем `date`>='date1' AND `date`<='date2'. Значит поле `date` не имеет смысла включать в индекс?
Это не так. Индекс используется для такого запроса. Но это последняя часть использованного составного индекса.
Пусть у Вас запрос WHERE a>10 and a<20 and b=11 and c=20
и индекс KEY(c,b, a) в таком случае последовательность такая:
1. Используется c=20 - первая часть индекса
2. Используется b=11 - вторая часть индекса
3. используется третья часть индекса для a>10 and a<20
Другой пример: KEY(c,a,b)
1. Используется c=20 - первая часть индекса
2. используется вторая часть индекса для a>10 and a<20
3. для оставшихся записей используется b=11 (using where), так как проще уже перебрать сами записи, чем обходить все ветви индекса для c=20, 10<a<20 и находить в индекса записи с b=11
Неактивен
Сразу не написал, но в моём случае в индексе есть два поля, каждое из которых ищется по больше/меньше, значит два этих поля точно нет смысла держать в индексе
А есть ли преимущество в использовании BETWEEN вместо больше/меньше?
Неактивен
BETWEEN синоним < >, преимущество не дает
Ваш случай просто проверьте, посмотрите что говорит EXPLAIN, какое значение key_len
Неактивен
тут описано простым языком http://spyvak.name/page/%D0%A0%D0%B0%D0 … 8-group-by
Неактивен
