Количество (*) против Количество (1) - SQL Server
Чтобы вызвать функцию без отладочной информации, вы должны явно указать gdb тип возвращаемого значения и аргументы, используя функцию-указатель функции. Итак, для вашего примера:
(gdb) print ((double (*) (double)) sqrt) (3)
$1 = 1.7320508075688772
7 ответов
Нет никакой разницы.
Причина:
Книги в Интернете говорят: «
COUNT ({[[ALL | DISTINCT] выражение] | *})«
« 1 »является ненулевым выражением: поэтому оно то же самое, что и COUNT (*) .
Оптимизатор распознает его так: тривиально.
То же, что EXISTS (SELECT * ... или EXISTS (SELECT 1 ...
Пример:
SELECT COUNT(1) FROM dbo.tab800krows
SELECT COUNT(1),FKID FROM dbo.tab800krows GROUP BY FKID
SELECT COUNT(*) FROM dbo.tab800krows
SELECT COUNT(*),FKID FROM dbo.tab800krows GROUP BY FKID
То же IO, тот же план, работы
Edit, август 2011 г.
Аналогичный вопрос по DBA.SE .
Edit, декабрь 2011 г.
COUNT (*) конкретно упоминается в ] ANSI-92 (ищите « Скалярные выражения 125 »)
Случай:
a) Если задано COUNT (*), то результатом будет количество элементов T.
То есть стандарт ANSI считает совершенно очевидным то, что вы имеете в виду. COUNT (1) был оптимизирован поставщиками СУБД из-за этого суеверия. В противном случае он был бы оценен. согласно ANSI
б) В противном случае пусть TX будет таблицей с одним столбцом, которая является результат применения <выражение значения> к каждой строке T и устранение нулевых значений. Если одно или несколько нулевых значений устраняется, то возникает условие завершения: warning-
Во всем RDBMS два способа рассчитать эквивалентны, с точки зрения какого результата они приводят. Относительно производительности я не наблюдал различия в производительности в SQL Server, но может стоить указать, что некоторый RDBMS, , например, PostgreSQL 11, имеет менее оптимальные реализации для COUNT(1), поскольку они проверяют на nullability выражения аргумента как видно в этом сообщении .
я нашел 10%-е различие в производительности для 1M строки при выполнении:
-- Faster
SELECT COUNT(*) FROM t;
-- 10% slower
SELECT COUNT(1) FROM t;
В SQL Server эти операторы приводят к одним и тем же планам.
Вопреки распространенному мнению, в Oracle они тоже.
SYS_GUID () в Oracle - довольно вычисление. интенсивная функция.
В моей тестовой базе данных t_even представляет собой таблицу с 1,000,000 строк
Этот запрос:
SELECT COUNT(SYS_GUID())
FROM t_even
выполняется в течение 48 секунд, поскольку функция должна оценивать каждый возвращенный SYS_GUID () , чтобы убедиться, что это не NULL .
Однако этот запрос:
SELECT COUNT(*)
FROM (
SELECT SYS_GUID()
FROM t_even
)
выполняется для 2 секунд, поскольку он даже не пытается вычислить SYS_GUID () (несмотря на то, что * является аргументом для COUNT (*) )
COUNT (*) и COUNT (1) одинаковы в случае результата и производительности.
Я ожидаю, что оптимизатор обеспечит отсутствие реальной разницы за пределами странных крайних случаев.
Как и во всем остальном, единственный реальный способ определить - это измерить ваши конкретные случаи.
Тем не менее, я всегда использовал COUNT (*) .
Очевидно, что COUNT (*) и COUNT (1) будут всегда возвращать один и тот же результат. Следовательно, если бы один был медленнее другого, это было бы эффективно из-за ошибки оптимизатора. Поскольку обе формы очень часто используются в запросах, для СУБД не имеет смысла оставлять такую ошибку не исправленной. Следовательно, вы обнаружите, что производительность обеих форм (вероятно) идентична во всех основных СУБД SQL.
SET STATISTICS TIME ON
select count(1) from MyTable (nolock) -- table containing 1 million records.
SQL Server Execution Times:
Время процессора = 31 мс, истекшее время = 36 мс.
select count(*) from MyTable (nolock) -- table containing 1 million records.
SQL Server Execution Times:
Время процессора = 46 мс, истекшее время = 37 мс.
Я прогонял это сотни раз, каждый раз очищая кэш... Время от времени результаты меняются, так как нагрузка на сервер меняется, но почти всегда счетчик(*) имеет более высокое время процессора.