Почему количество (*) в типе оператора SQL подготовки действительно мало? - PullRequest
0 голосов
/ 06 июня 2011

Я обнаружил, что "count () over ()" будет намного быстрее по сравнению с "select count () from table".

например

использовать счет (*) более

with CTE as( select col_A,col_B,totalNumber=count(*) over() from table1 where conditions..) select totalNumber from CTE

использовать выбор счетчика (*) из (или также использовать счет (1))

select count(*) from table1 where conditions..

В моем локальном тестировании на SQL Server 2K5 значение () over * будет в 4 раза быстрее, если критерии поискасложный, и возвращаемые строки большие.

Но почему подсчет (**) более быстрый?

Спасибо за объявление.

Vance

Обновление

Я думаю, что я действительно упустил некоторые детали:

На самом деле я использую sql "подготовить заявление" для своего теста, например:

exec sp_executesql N'SELECT count(*) FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%'</p> <p>Execution Plan says "HashMatch" cost 61%, others is "index seek". And the execution time will be 1484ms and logical reads around 4000.

Это медленно, когда сравнивается с

SELECT count(*) FROM tableA WHERE (aaa in('XXXXXXX-XXXX-XXX')) AND (bbb like '%AAA%') Execution plan says "clustered index seek" cost 98%. And the execution time is 46ms and logical reads will be 8000.

И если изменяется в первом sql на:

exec sp_executesql N'with CTE as( SELECT total=count(*) over () FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)) select top 1total from cte', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%' Execution plan says "clustered index seek 58%', no "hashmatch join" occurs. </p> <p>And the execution time is 15ms and logical reads is: 8404.

так, "hash match join join" сильно влияет на производительность?

...