SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
FROM PRACOWNICY
GROUP BY NR_DZIALU
HAVING NR_DZIALU = 30
или же
SELECT NR_DZIALU, COUNT (NR_DZIALU) AS LICZ_PRAC_DZIALU
FROM PRACOWNICY
WHERE NR_DZIALU = 30
GROUP BY NR_DZIALU


Я ожидал, что предложение WHERE будет быстрее, но, возможно, они будут оптимизированы точно так же.
Теория (теоретически я имею в виду Стандарт SQL) гласит, что WHERE ограничивает набор результатов перед возвратом строк, а HAVING ограничивает набор результатов после переноса всех строк. Так ГДЕ быстрее. В СУБД, совместимых со стандартом SQL, в этом отношении используйте HAVING только там, где вы не можете поместить условие в WHERE (например, вычисляемые столбцы в некоторых СУБД).
Вы можете просто просмотреть план выполнения для обоих и проверить сами, ничто не сравнится с этим (измерение для вашего конкретного запроса в вашей конкретной среде с вашими данными).
под Sybase DB у него одинаковое время выполнения для 150 строк :)
Я сказал план выполнения, где вы можете увидеть, какие шаги будет выполнять база данных для получения ваших данных. 150 строк слишком мало, чтобы заметить разницу во времени выполнения, но если план отличается, то это будет иметь значение для таблиц с большим количеством строк. "установить план показа" перед выполнением запроса ...
... должен предоставить вам данные о Sybase. Проверьте эту ссылку для получения дополнительной информации: groups.google.com/group/comp.databases.sybase/browse_thread/…
FWIW, в MS SQL Server 2005 план выполнения идентичен.
не будет ли это зависеть от размера таблицы и подмножества и стоимости предложения where по всей таблице по сравнению со стоимостью предложения where против подмножества?
Здесь есть некоторые фундаментальные недоразумения. Стандарт SQL говорит, что возвращает оператор, с точки зрения его входных данных, и ничего не говорит о производительности.
Это может зависеть от двигателя. Например, MySQL применяет HAVING почти последним в цепочке, что означает, что для оптимизации почти нет места. Из руководство по эксплуатации:
The HAVING clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT is applied after HAVING.)
Я считаю, что это поведение одинаково в большинстве движков баз данных SQL, но я не могу этого гарантировать.
Хех, "это зависит от движка, но я считаю, что все они так себя ведут" :-)
Что ж, я могу говорить только о том, что знаю, и размышлять об остальном :)
Эти два запроса эквивалентны, и ваш оптимизатор запросов СУБД должен распознает это и создает один и тот же план запроса. Может и нет, но ситуацию довольно просто распознать, поэтому я ожидаю, что любая современная система - даже Sybase - справится с этим.
Для применения условий к групповым функциям следует использовать предложения HAVING, в противном случае их можно переместить в условие WHERE. Например. если вы хотите ограничить свой запрос группами, у которых COUNT (DZIALU)> 10, скажем, вам нужно будет поместить условие в HAVING, потому что оно действует на группы, а не на отдельные строки.
Сказать, что они будут оптимизировать, на самом деле не означает взять на себя управление и сказать компьютеру, что делать. Я согласен с тем, что использование наличия не является альтернативой предложению where. Имея специальное использование применения к группе, где использовалось что-то вроде sum (), и вы хотите ограничить набор результатов, чтобы показывать только группы, имеющие sum ()> 100 как таковые. Имея работает по группам, Где работает по рядам. Это яблоки и апельсины. Так что на самом деле их не следует сравнивать, поскольку это два очень разных животных.
Оба оператора будут иметь одинаковую производительность, поскольку SQL Server достаточно умен, чтобы проанализировать оба одинаковых оператора в похожем плане.
Таким образом, не имеет значения, используете ли вы в своем запросе WHERE или HAVING.
Но в идеале вы должны использовать предложение WHERE синтаксически.
«ГДЕ» быстрее, чем «ИМЕЕТ»!
Чем сложнее группировка запроса, тем медленнее "HAVING" будет выполнять сравнение, потому что: "HAVING" "filter" будет иметь дело с большим количеством результатов, а также является дополнительным циклом "filter"
"HAVING" также будет использовать больше памяти (RAM)
В то же время при работе с небольшими данными - разница незначительна, и ее можно полностью игнорировать.
«Имея» работает медленнее, если сравнивать с большим объемом данных, потому что он работает с группой записей, а «ГДЕ» работает с количеством строк.
"Где" ограничивает результаты перед переносом всех строк, а "Имея" ограничивает результаты после переноса всех строк.
К вашему сведению, я собрал методы оптимизации, касающиеся предложения, на случай, если кто-то захочет оптимизировать запрос. junaidtechblog.wordpress.com/2019/09/04/…