Какой оператор SQL быстрее? (ИМЕЮЩИЙ против ГДЕ ...)

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

К вашему сведению, я собрал методы оптимизации, касающиеся предложения, на случай, если кто-то захочет оптимизировать запрос. junaidtechblog.wordpress.com/2019/09/04/…

Junaid Ali 07.09.2019 15:16
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
44
1
40 645
8
Перейти к ответу Данный вопрос помечен как решенный

Ответы 8

Я ожидал, что предложение WHERE будет быстрее, но, возможно, они будут оптимизированы точно так же.

Ответ принят как подходящий

Теория (теоретически я имею в виду Стандарт SQL) гласит, что WHERE ограничивает набор результатов перед возвратом строк, а HAVING ограничивает набор результатов после переноса всех строк. Так ГДЕ быстрее. В СУБД, совместимых со стандартом SQL, в этом отношении используйте HAVING только там, где вы не можете поместить условие в WHERE (например, вычисляемые столбцы в некоторых СУБД).

Вы можете просто просмотреть план выполнения для обоих и проверить сами, ничто не сравнится с этим (измерение для вашего конкретного запроса в вашей конкретной среде с вашими данными).

под Sybase DB у него одинаковое время выполнения для 150 строк :)

M_1 30.11.2008 11:56

Я сказал план выполнения, где вы можете увидеть, какие шаги будет выполнять база данных для получения ваших данных. 150 строк слишком мало, чтобы заметить разницу во времени выполнения, но если план отличается, то это будет иметь значение для таблиц с большим количеством строк. "установить план показа" перед выполнением запроса ...

Vinko Vrsalovic 30.11.2008 12:19

... должен предоставить вам данные о Sybase. Проверьте эту ссылку для получения дополнительной информации: groups.google.com/group/comp.databases.sybase/browse_thread/‌…

Vinko Vrsalovic 30.11.2008 12:20

FWIW, в MS SQL Server 2005 план выполнения идентичен.

Sören Kuklau 30.11.2008 13:18

не будет ли это зависеть от размера таблицы и подмножества и стоимости предложения where по всей таблице по сравнению со стоимостью предложения where против подмножества?

JoeBrockhaus 31.07.2013 23:48

Здесь есть некоторые фундаментальные недоразумения. Стандарт SQL говорит, что возвращает оператор, с точки зрения его входных данных, и ничего не говорит о производительности.

philipxy 02.06.2017 03:59

Это может зависеть от двигателя. Например, 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, но я не могу этого гарантировать.

Хех, "это зависит от движка, но я считаю, что все они так себя ведут" :-)

Vinko Vrsalovic 30.11.2008 11:48

Что ж, я могу говорить только о том, что знаю, и размышлять об остальном :)

Eran Galperin 30.11.2008 11:48

Эти два запроса эквивалентны, и ваш оптимизатор запросов СУБД должен распознает это и создает один и тот же план запроса. Может и нет, но ситуацию довольно просто распознать, поэтому я ожидаю, что любая современная система - даже Sybase - справится с этим.

Для применения условий к групповым функциям следует использовать предложения HAVING, в противном случае их можно переместить в условие WHERE. Например. если вы хотите ограничить свой запрос группами, у которых COUNT (DZIALU)> 10, скажем, вам нужно будет поместить условие в HAVING, потому что оно действует на группы, а не на отдельные строки.

Сказать, что они будут оптимизировать, на самом деле не означает взять на себя управление и сказать компьютеру, что делать. Я согласен с тем, что использование наличия не является альтернативой предложению where. Имея специальное использование применения к группе, где использовалось что-то вроде sum (), и вы хотите ограничить набор результатов, чтобы показывать только группы, имеющие sum ()> 100 как таковые. Имея работает по группам, Где работает по рядам. Это яблоки и апельсины. Так что на самом деле их не следует сравнивать, поскольку это два очень разных животных.

Оба оператора будут иметь одинаковую производительность, поскольку SQL Server достаточно умен, чтобы проанализировать оба одинаковых оператора в похожем плане.

Таким образом, не имеет значения, используете ли вы в своем запросе WHERE или HAVING.

Но в идеале вы должны использовать предложение WHERE синтаксически.

«ГДЕ» быстрее, чем «ИМЕЕТ»!

Чем сложнее группировка запроса, тем медленнее "HAVING" будет выполнять сравнение, потому что: "HAVING" "filter" будет иметь дело с большим количеством результатов, а также является дополнительным циклом "filter"

"HAVING" также будет использовать больше памяти (RAM)

В то же время при работе с небольшими данными - разница незначительна, и ее можно полностью игнорировать.

«Имея» работает медленнее, если сравнивать с большим объемом данных, потому что он работает с группой записей, а «ГДЕ» работает с количеством строк.

"Где" ограничивает результаты перед переносом всех строк, а "Имея" ограничивает результаты после переноса всех строк.

Другие вопросы по теме