| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
HELP!!!Странная сортировка при GROUP BY [D7]
vlgrig1961 © (2011-03-30 09:27:00)Здравствуйту уважаемые! Возникла такая проблема
База Oracle 8 запросы с использованием group by по стринговым индексам сортировались нормально по алфавиту.
(select KltName,KltKod,sum(Summa) from Jurnal group by KltName,KltKod)
Перешел на Oracle 9.2 базу перенес экспорт/импорт-ом
(единственно в старой базе индексы хранились в tablespace USR, вместе с данными, а вновой перенес в отдельный tablespace)
Сейчас теже запросы сортируются по длине поля KltName, т.е. сначала все длиной 5 символов, потов 6 и т.д. по возрастанию, а если одинаковой длины, то они по алфавиту.
Не могу понять в чем причина???????????
Может кто подскажет!!!!!! Заранее спасибо.
sniknik (2011-03-31 13:19:00) [1]> НЕ УСКОРИТ выборку.))
> если Вы оппонировали не этому тезису
как я мог "оппонировать к этому тезису" если вообще не говорил тезисов/конкретного?
я согласился с АП (не в понимании процесса, оно у нас похоже разное, а по сути), в том, что order by / индекс на поле / версия / вообще что угодно, может повлиять на план, а от него точно зависит и скорость выполнения. что значит оно МОЖЕТ УСКОРИТЬ выборку.
Кщд (2011-03-31 12:23:00) [2]>sniknik © (31.03.11 11:27) [31]
>ты моих "если нужно" "а если то" в упор не видишь?
налицо взаимное недопонимание.)
я всего лишь утверждал, что наличие индексированного поля в секции order by, следующей за секцией group by, НЕ УСКОРИТ выборку.))
если Вы оппонировали не этому тезису, то вопрос закрыт.
sniknik (2011-03-31 11:27:00) [3]> а то что при дополнительной операции в некоторых случаях может работать быстрее.
ну, вообще то, order by тут это не дополнительная операция, скорее параметр...
почему вы рассматриваете это как программу, где написание доп кода означает доп действия?
селект это скорее как процедура, где это доп. параметр, и он может пустить обработку по другой ветке, что кстати и произошло у меня (второй скриншот). т.е. пишешь вроде лишние команды, а действий меньше.
> распараллеливание появилось с 2005?
> при параллельном сканировании индекса, сортировка появится в плане.
> и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.
ты моих "если нужно" "а если то" в упор не видишь? пытаешься свести все к частному случаю когда не используется. зачем? и так понятно, что если "если не сработает" и даже при наличие индекса будет выбран полный скан, как и в случае без индекса, то никакого влияния не будет...
в КЭП-а играешься?
Кщд (2011-03-31 10:59:00) [4]>sniknik © (31.03.11 10:25) [27]
>на это вообще нельзя закладываться
из плана явно видно, что в случае с наличием индекса, сервер не производит сортировку. т.о. оптимизатор как раз таки "закладывается" на то, что результирующий набор отсортирован.
>да. но не думаю, что версия, что то изменит в плане...
распараллеливание появилось с 2005?
при параллельном сканировании индекса, сортировка появится в плане.
и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.
Anatoly Podgoretsky (2011-03-31 10:59:00) [5]> sniknik (31.03.2011 10:27:28) [28]
Я не про это, а то что при дополнительной операции в некоторых случаях может
работать быстрее.
sniknik (2011-03-31 10:27:00) [6]> в плане
Anatoly Podgoretsky © (30.03.11 12:11) [10]
> Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет другой план исполнения
план, другой. это очевидно по скриншотам.
sniknik (2011-03-31 10:25:00) [7]> на это можно закладываться
на это вообще нельзя закладываться (иначе бы в доке было явно написано что group by = order by), и в ветке много это повторяли, но можно основываясь на этом, по предполагать, как оно работает.
> версия сервера - 2000?
да. но не думаю, что версия, что то изменит в плане "делает так как ему кажется лучше, и использует индекс если оно нужно, а если использует то может ускорить", про что, по смыслу, говорилось ранее.
Кщд (2011-03-31 10:15:00) [8]>sniknik © (31.03.11 10:05) [25]
в плане с индексом не видно сортировки.
очевидно, MS SQL считает набор УЖЕ отсортированным при сканировании индекса. на это можно закладываться, но не при параллельном сканировании.
версия сервера - 2000?
sniknik (2011-03-31 10:05:00) [9]> нет индекса и есть
вернее наоборот есть и нет.
количество действий посчитать?
sniknik (2011-03-31 10:04:00) [10]но проблем, вот с сортировкой, нет индекса и есть
http://saveimg.ru/show-image.php?id=a47c6902f7de7a82945dc981ee995a4f
Кщд (2011-03-31 09:57:00) [11]>sniknik © (31.03.11 09:55) [22]
Кщд (31.03.11 09:22) [21]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.
я говорил именно об этом
sniknik (2011-03-31 09:55:00) [12]> никакой магии - ожидаемо индекс не оказывает влияния.
магия, блин
http://saveimg.ru/show-image.php?id=e0eebbe0752624ed4e1e071e39d6d81e
надеюсь разницу в картинках объяснять не надо?
Кщд (2011-03-31 09:22:00) [13]>sniknik © (31.03.11 07:54) [20]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.
а это, в общем случае, не так.
не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится)
в общем случае, сортировки не будет, т.к. и в Oracle и в MS SQL, например, существует распараллеливание, т.е. сканирование, в частности, индекса не будет сериализованным, последовательным.
вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.
проверил до того, как написать первый пост
никакой магии - ожидаемо индекс не оказывает влияния.
sniknik (2011-03-31 07:54:00) [14]> Какое использование индекса в сгруппированном наборе?
не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится). использовать в процессе уже готовый сортированный индекс проще чем сначала сортировать, или сканировать не сортированный (для обеспечения оригинального порядка).
а раз проще/меньше действий то и быстрее тоже.
p.s. вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.
Кщд (2011-03-31 07:06:00) [15]>Anatoly Podgoretsky © (30.03.11 12:11) [10]
Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет
другой план исполнения
Какое использование индекса в сгруппированном наборе?
sniknik (2011-03-30 14:53:00) [16]> И с Информиксом тебе тоже пока везет
я таким никогда не пользуюсь. приведенный запрос чисто ради попытки понимания как оно там "у нутрях" работает.
Anatoly Podgoretsky (2011-03-30 14:05:00) [17]> sniknik (30.03.2011 12:52:12) [12]
И с Информиксом тебе тоже пока везет
OW (2011-03-30 14:02:00) [18]там же он пишет
group by
o HAS NEVER HAD TO SORT
o ALWAYS DID A BINARY SORT (meaning for most of the world, the sort
would have been WRONG even if it happened by accident)
Игорь Шевченко (2011-03-30 13:01:00) [19]есть такая штука, как стандарт SQL, в нем ясно английским по белому написано, что сортированный набор появляется после клаузы ORDER BY и никак иначе.
Игорь Шевченко (2011-03-30 12:59:00) [20]sniknik © (30.03.11 12:52) [12]
> я так понимаю и в оракле будет/есть, если например по числовому
> полю сделать... а у него текстовое, и сортировка тоже присутствует,
> просто оракл в какой то момент "решил" что манипулировать
> ему проще не просто отсортированными строками, а еще и разделенными
> по длине...
Я вот про MS SQL, информикс и прочее сказки не рассказываю, давай ты про Oracle их не будешь рассказывать.
| |
Страницы: 