| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Есть ли разница, что указывать вместо звездочки в count(*) ?
Piter © (2009-10-30 15:51:00)А есть ли разница в каких-то случаях, что писать внутри count?
Может ли быть отличиеcount(*)отcount(PK_name), где PK_name - наименование поля primary key?
Отличие в результатах (?!), в скорости исполнения? Что идеологически правильнее, почему?
Кщд (2009-11-09 14:21:00) [1]>salexn (09.11.09 12:57) [33]
отличный нюанс - главное, подходящий для всех СУБД
salexn (2009-11-09 12:57:00) [2]Есть еще один нюанс.
Предположим, что на какой-то столбец в таблице наложили ограничение по доступности - не доступен для чтения.
Тогда SELECT count(*) не отработает, как и не отработает запрос
SELECT COUNT(1)
Кщд (2009-11-06 19:01:00) [3]>ANB (06.11.09 13:01) [31]
сильно осложняют особенно те, которые латать в 10-ке и не собираются)
впрочем, надежды скачать 10.2.0.5 не оставляю
подождем 11.2 и будем кочевать - как обычно
ANB (2009-11-06 13:01:00) [4]
> перенесенной на 10g
На 10-ке еще баги выплыли. Некоторые сильно усложняют жизнь.
Кщд (2009-11-05 08:44:00) [5]>Игорь Шевченко © (04.11.09 16:04) [29]
>Безусловно. Лечилось изменением запроса и следованием мантре >"оптимизатор всегда прав" (он в 99,9% оказывается прав).
на боевой системе изменение запроса не всегда возможно: элементарно нет понимания, какие данные должен вернуть запрос с точки зрения бизнеса, а знание это давно утеряно, т.к. разработчик уволился, постановщик болеет, а заказчик почил в бозе
но проследить логику, заложенную разработчиком и заставить oracle делать именно то, что от него хотели - можно
>Я стараюсь использовать хинты как можно реже, потому что без хинтов план запроса будет более оптимально подстраиваться под данные.
абсолютно согласен
>Это не тяжелое наследие индийской культуры, это очень разумное >положение: работает - не трогай
не согласен: ядро эволюционирует, но костыли остаются - это неправильно
правило "работает - не трогай" работает для прикладных систем - спора нет, но такой подход ужасен в СУБД
сбор статистики обязательно полезен был бы и для словаря данных, но - увы - вероятно, нет ресурсов на переписывание груды индийского кода
явное хинтование rule'ом в ядре - это костыль и признание немощности разработчиком
табу на сбор статистики в SYS - это ли не бред?)
>Сбор статистики еще сам по себе занимает ресурсы, что тоже не >положительно сказывается на производительности.
здесь можно лавировать технологическими перерывами и параметрами сбора статистики, но когда мы на стенде сделали сбор статистики на древней системе, перенесенной на 10g, испытали ужас и потрясение
Игорь Шевченко (2009-11-04 16:04:00) [6]Кщд (04.11.09 15:09) [28]
> наверняка с таким встречались?
Безусловно. Лечилось изменением запроса и следованием мантре "оптимизатор всегда прав" (он в 99,9% оказывается прав). Я стараюсь использовать хинты как можно реже, потому что без хинтов план запроса будет более оптимально подстраиваться под данные.
> во внутренних представлениях Oracle до сих пор можно встретить
> /*+ rule*/(тяжелое наследие индийской культуры)
Это не тяжелое наследие индийской культуры, это очень разумное положение: работает - не трогай. Если для чего-то гарантировано известно, что по правилам будет работать быстро и надежно, то пусть работает по правилам. В конце концов сам оптимизатор по правилам гораздо быстрее отрабатывает фазу подготовки запроса к исполнению.
> сбор статистики жестко ударит по производительности
Сбор статистики еще сам по себе занимает ресурсы, что тоже не положительно сказывается на производительности.
Кщд (2009-11-04 15:09:00) [7]>Игорь Шевченко © (04.11.09 14:08) [26]
на некоторых старых системах это невозможно, т.к. сбор статистики жестко ударит по производительности, ввиду того, что разлетятся планы
а ресурсов на переписывание системы просто нет...
есть и второй аспект: иногда(особенно на сложных запросах), оптимизатор так забавно, простите, оптимизирует, что результаты запроса с нестабилизированным планом в худшую сторону(т.е. попросту бредовые) отличаются от явно прохинтованных - наверняка с таким встречались?
это случается крайне редко и, конечно, вовсе не повод не собирать статистику или вставлять хинты куда ни попадя
имеется и третий аспект проблемы: во внутренних представлениях Oracle до сих пор можно встретить /*+ rule*/(тяжелое наследие индийской культуры) - поэтому в таких случаях, очевидно, собранная статистика не спасет
Anatoly Podgoretsky (2009-11-04 14:46:00) [8]> stakan (04.11.2009 12:20:24) [24]
В данном виде возмодно просто укажет количество записей, которое ему уже известно, без обращения к таблице или индексам.
Игорь Шевченко (2009-11-04 14:08:00) [9]Кщд (04.11.09 13:47) [25]
> тогда приходится стабилизировать план вручную
Или чаще собирать статистику :)
Кщд (2009-11-04 13:47:00) [10]>stakan (04.11.09 12:20) [24]
>Просто приятно удивила догадливость оптимизатора. Честно говоря, думал, что >при запросах select count(*) from t оптимизатор выберет table scan.
хуже, когда догадливость переходит в "догадливость" для сложных запросов
тогда приходится стабилизировать план вручную
stakan (2009-11-04 12:20:00) [11]
> Oracle использует тот метод доступа, который является более
> подходящим - согласно ли правилам или собранной статистике(RBO
> и CBO, соответственно, - что у вас там?) - поэтому четкие
> утверждения о том, что всегда используется Index FFS, безосновательны.
>
> С BI индексом - тоже всё ясно, т.к. он содержит null-значения,
> в отличие от B-tree индекса Oracle.
> Собирайте статистику и не ищите магию.
>
Да это все понятно и логично, никакой магии нет. И то что
> всегда используется Index FFS
я не утверждал.
Просто приятно удивила догадливость оптимизатора. Честно говоря, думал, что при запросахselect count(*) from tоптимизатор выберет table scan.
Кщд (2009-11-04 09:59:00) [12]>stakan (03.11.09 14:15) [21]
Oracle использует тот метод доступа, который является более подходящим - согласно ли правилам или собранной статистике(RBO и CBO, соответственно, - что у вас там?) - поэтому четкие утверждения о том, что всегда используется Index FFS, безосновательны.
С BI индексом - тоже всё ясно, т.к. он содержит null-значения, в отличие от B-tree индекса Oracle.
Собирайте статистику и не ищите магию.
Игорь Шевченко (2009-11-03 15:16:00) [13]stakan (03.11.09 14:15) [21]
> Oracle использует INDEX FAST FULL SCAN без доступа к таблице
> даже при запросе вида select count(*).
Если по списку предикатов определяется, что достаточно сканировать индекс. В противном случае будут сканироваться данные.
Льюис на эту тему достаточно подробно пишет, в "Основах стоимостной оптимизации"
stakan (2009-11-03 14:15:00) [14]Наткнулся на интересную особенность.
Oracle использует INDEX FAST FULL SCAN без доступа к таблице даже при запросе видаselect count(*).
Причем на запросах вида select count(PK_NAME) может использовать НЕ индекс по полю PK_NAME, а индекс по другому not null полю. А если есть bitmap index, то использует его, даже если этот индекс построен по полю nullable.
Inovet (2009-11-02 13:35:00) [15]> [19] Кщд (02.11.09 12:38)
> ещё раз: при отсутствии null-значений полей - искать нечего
> - различных значений просто не будет
Вот и вернётся 0 записей.
Кщд (2009-11-02 12:38:00) [16]>Inovet © (02.11.09 12:22) [18]
Здесь(Медвежонок Пятачок © (30.10.09 16:23) [3]) всё понятно написано
>Не призван он ничего доказать или опровергнуть, а показать различные значения сабжа
ещё раз: при отсутствии null-значений полей - искать нечего - различных значений просто не будет
Inovet (2009-11-02 12:22:00) [17]> [17] Кщд (02.11.09 11:36)
> >Inovet © (02.11.09 10:09) [16]
> речь о том, что иллюстративность Вашего запроса весьма и
> весьма зависит от "магии данных"
> поэтому что именно он(запрос) призван доказать или опровергнуть
> - не ясно)
Не призван он ничего доказать или опровергнуть, а показать различные значения сабжа, если таковые найдутся, можно убрать HAVING и искать глазами.
Кщд (2009-11-02 11:36:00) [18]>Inovet © (02.11.09 10:09) [16]
речь о том, что иллюстративность Вашего запроса весьма и весьма зависит от "магии данных"
поэтому что именно он(запрос) призван доказать или опровергнуть - не ясно)
Inovet (2009-11-02 10:09:00) [19]> [15] Кщд (02.11.09 08:45)
> >Inovet © (30.10.09 20:33) [14]
> у меня данный запрос не выводит ничего - значит, разницы
> никакой нет, так?))
В чём разница выше отвечали, а запрос одлжен её показать, я всё же наверно такой имел ввиду
SELECT FLD1, COUNT(FLD1), COUNT(FLD2), COUNT(*)
FROM TBL
GROUP BY FLD1
HAVING COUNT(FLD1) <> COUNT(FLD2) OR COUNT(FLD2) <> COUNT(*)
Кщд (2009-11-02 08:45:00) [20]>Inovet © (30.10.09 20:33) [14]
у меня данный запрос не выводит ничего - значит, разницы никакой нет, так?))
| |
Страницы: 