Comments 13
Стилистически текст переведен настолько топорно, что еле «допарсил» до конца. Может все-таки давать подобное вычитывать людям «в теме» перед публикацией?
На вкус и цвет. Если вам не нравится — можете перевести лучше. Ссылка на исходник в статье
Да в общем-то и текст местами так себе. Например, очень доставляет читать про замену HAVING на WHERE. С учетом того, что типовой HAVING содержит условия на группы (например, (число строк в группе > 1), и в терминах WHERE просто выражен быть не может. А тот пример, что приведен, никто через HAVING и писать не станет.
Это общие положения. Здесь изложен текст для тех, что начинает писать на SQL. Мне кажется это очевидно. Например совершенно верно, что сначала нужно отобрать нужные записи, а потом их группировать то есть WHERE + GROUP BY, а не наоборот GROUP BY + HAVING
Текст для тех кто начинает — и при этом где-то половина об оптимизациях? Мне кажется, что это как раз некоторый недостаток данного текста, что автор не определился, для кого он — и поэтому мешает понятия разных уровней.
>WHERE + GROUP BY, а не наоборот GROUP BY + HAVING
Что сначала отобрать, а потом группировка — это разумно, но речь была слегка не про это.
Идея заменить HAVING (условия в общем случае на свойства группы, то есть на агрегаты) на WHERE (условия на строки) — она весьма частная, и в общем случае невозможна. Из where на строки ничего не следует про свойства групп (про count в группе, например).
В таком виде давать ее начинающим — только путать.
>WHERE + GROUP BY, а не наоборот GROUP BY + HAVING
Что сначала отобрать, а потом группировка — это разумно, но речь была слегка не про это.
Идея заменить HAVING (условия в общем случае на свойства группы, то есть на агрегаты) на WHERE (условия на строки) — она весьма частная, и в общем случае невозможна. Из where на строки ничего не следует про свойства групп (про count в группе, например).
В таком виде давать ее начинающим — только путать.
Некоторые «антипаттерны» — неверны, по крайней мере для MSSQLSERVER.
1. Exists всегда работает быстрее, чем inner join, поэтому там, где вы в состоянии применить коррелированный подзапрос вместо соединения — всегда используйте exists.
2. Порядок таблиц в join как то влияет на выбор плана только с опцией FORCE ORDER. Хотя можно еще попытаться повлиять на порядок соединения расставляя скобки ( ).
Двигать вверх-вниз тяжелые таблицы по тексту запроса — смысла нет, оптимизатор всё равно всё решит на основе статистики.
3. in и or в простом случае — совершенно эквивалентны, и приведенный пример с between и <= и >= — тоже. И индексы они будут использовать совершенно одинаково.
4. Where и Having имеют совершенно разный смысл, и, разумеется, могут быть эквивалентны только в совершенно специальных случаях, вроде приведенного примера. Только вот эффективность того или иного варианта будет зависеть от кучи условий. Например, если по state — нет индекса, или наоборот, индекс есть, но он — низкоселективный, например, там всего 3-4 варианта значений — запрос с having — будет быстрее, или, по крайней мере — не медленнее запроса с where. Более того, мы сразу пресечем поползновения оптимизатора построить какой-нибудь «левый» план, а заставим сервер просканировать индекс, кластерный индекс или таблицу, а потом отобрать в небольшом списке результатов.
Это может быть, например, полезно, если мы хотим, чтобы запрос вел себя предсказуемо, и не зависел от parameter sniffing.
Ну и т.д.
1. Exists всегда работает быстрее, чем inner join, поэтому там, где вы в состоянии применить коррелированный подзапрос вместо соединения — всегда используйте exists.
2. Порядок таблиц в join как то влияет на выбор плана только с опцией FORCE ORDER. Хотя можно еще попытаться повлиять на порядок соединения расставляя скобки ( ).
Двигать вверх-вниз тяжелые таблицы по тексту запроса — смысла нет, оптимизатор всё равно всё решит на основе статистики.
3. in и or в простом случае — совершенно эквивалентны, и приведенный пример с between и <= и >= — тоже. И индексы они будут использовать совершенно одинаково.
4. Where и Having имеют совершенно разный смысл, и, разумеется, могут быть эквивалентны только в совершенно специальных случаях, вроде приведенного примера. Только вот эффективность того или иного варианта будет зависеть от кучи условий. Например, если по state — нет индекса, или наоборот, индекс есть, но он — низкоселективный, например, там всего 3-4 варианта значений — запрос с having — будет быстрее, или, по крайней мере — не медленнее запроса с where. Более того, мы сразу пресечем поползновения оптимизатора построить какой-нибудь «левый» план, а заставим сервер просканировать индекс, кластерный индекс или таблицу, а потом отобрать в небольшом списке результатов.
Это может быть, например, полезно, если мы хотим, чтобы запрос вел себя предсказуемо, и не зависел от parameter sniffing.
Ну и т.д.
RE: Неплохо для языка, который был разработан в начале 1970-х, верно?
(из вики) В 1986 году первый стандарт языка SQL был принят ANSI. Вики опять же говорит что группа похожих экспериментальных языков и СУБД разрабатывалась в 70х. Для меня интересен факт что великий ANSI SQL 1986 моложе великого же MS Excel DOS (1985)
(из вики) В 1986 году первый стандарт языка SQL был принят ANSI. Вики опять же говорит что группа похожих экспериментальных языков и СУБД разрабатывалась в 70х. Для меня интересен факт что великий ANSI SQL 1986 моложе великого же MS Excel DOS (1985)
Большая часть утверждений верная, но все эти утверждения, тут же убиваются о приведенные примеры, не проявляясь в них.
Спасибо за статью, жду следующие части.
habr.com/ru/post/465975 вторая часть
Sign up to leave a comment.
Руководство по SQL: Как лучше писать запросы (Часть 1)