-
> Какое использование индекса в сгруппированном наборе?
не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится). использовать в процессе уже готовый сортированный индекс проще чем сначала сортировать, или сканировать не сортированный (для обеспечения оригинального порядка).
а раз проще/меньше действий то и быстрее тоже.
p.s. вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.
-
>sniknik © (31.03.11 07:54) [20]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.
а это, в общем случае, не так.
не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится)
в общем случае, сортировки не будет, т.к. и в Oracle и в MS SQL, например, существует распараллеливание, т.е. сканирование, в частности, индекса не будет сериализованным, последовательным.
вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.
проверил до того, как написать первый пост
никакой магии - ожидаемо индекс не оказывает влияния.
-
-
>sniknik © (31.03.11 09:55) [22]
Кщд (31.03.11 09:22) [21]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.
я говорил именно об этом
-
-
> нет индекса и есть
вернее наоборот есть и нет.
количество действий посчитать?
-
>sniknik © (31.03.11 10:05) [25]
в плане с индексом не видно сортировки.
очевидно, MS SQL считает набор УЖЕ отсортированным при сканировании индекса. на это можно закладываться, но не при параллельном сканировании.
версия сервера - 2000?
-
> на это можно закладываться
на это вообще нельзя закладываться (иначе бы в доке было явно написано что group by = order by), и в ветке много это повторяли, но можно основываясь на этом, по предполагать, как оно работает.
> версия сервера - 2000?
да. но не думаю, что версия, что то изменит в плане "делает так как ему кажется лучше, и использует индекс если оно нужно, а если использует то может ускорить", про что, по смыслу, говорилось ранее.
-
> в плане
Anatoly Podgoretsky © (30.03.11 12:11) [10]
> Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет другой план исполнения
план, другой. это очевидно по скриншотам.
-
> sniknik (31.03.2011 10:27:28) [28]
Я не про это, а то что при дополнительной операции в некоторых случаях может
работать быстрее.
-
>sniknik © (31.03.11 10:25) [27]
>на это вообще нельзя закладываться
из плана явно видно, что в случае с наличием индекса, сервер не производит сортировку. т.о. оптимизатор как раз таки "закладывается" на то, что результирующий набор отсортирован.
>да. но не думаю, что версия, что то изменит в плане...
распараллеливание появилось с 2005?
при параллельном сканировании индекса, сортировка появится в плане.
и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.
-
> а то что при дополнительной операции в некоторых случаях может работать быстрее.
ну, вообще то, order by тут это не дополнительная операция, скорее параметр...
почему вы рассматриваете это как программу, где написание доп кода означает доп действия?
селект это скорее как процедура, где это доп. параметр, и он может пустить обработку по другой ветке, что кстати и произошло у меня (второй скриншот). т.е. пишешь вроде лишние команды, а действий меньше.
> распараллеливание появилось с 2005?
> при параллельном сканировании индекса, сортировка появится в плане.
> и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.
ты моих "если нужно" "а если то" в упор не видишь? пытаешься свести все к частному случаю когда не используется. зачем? и так понятно, что если "если не сработает" и даже при наличие индекса будет выбран полный скан, как и в случае без индекса, то никакого влияния не будет...
в КЭП-а играешься?
-
>sniknik © (31.03.11 11:27) [31]
>ты моих "если нужно" "а если то" в упор не видишь?
налицо взаимное недопонимание.)
я всего лишь утверждал, что наличие индексированного поля в секции order by, следующей за секцией group by, НЕ УСКОРИТ выборку.))
если Вы оппонировали не этому тезису, то вопрос закрыт.
-
> НЕ УСКОРИТ выборку.))
> если Вы оппонировали не этому тезису
как я мог "оппонировать к этому тезису" если вообще не говорил тезисов/конкретного?
я согласился с АП (не в понимании процесса, оно у нас похоже разное, а по сути), в том, что order by / индекс на поле / версия / вообще что угодно, может повлиять на план, а от него точно зависит и скорость выполнения. что значит оно МОЖЕТ УСКОРИТЬ выборку.
|
Есть новые 
Нет новых [134431 +15][b:0][p:0]