只是想知道你们中是否有人使用Count(1)
而不是Count(*)
,在性能上是否有显着的差异,或者这只是一个从过去的日子里继承下来的习惯?
具体数据库为SQL Server 2005
。
发布于 2009-08-03 10:36:52
这是没有区别的。
原因:
Books on-line说"
COUNT ( { [ [ ALL | DISTINCT ] expression ] | * } )
“
"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,同样的计划,同样的工作
编辑,2011年8月
编辑,2011年12月
ANSI-92中特别提到了COUNT(*)
(查找"Scalar expressions 125
")
案例:
a)如果指定COUNT(*),则结果是T的基数。
也就是说,ANSI标准将其识别为显而易见的意思。由于这种迷信,COUNT(1)
已经被关系型数据库供应商优化了。否则,它将按照ANSI进行计算
b)否则,让TX是单列表,它是将应用到T的每一行并消除NULL值的结果。如果消除了一个或多个空值,则会引发完成条件: warning-
发布于 2009-08-03 10:34:38
在SQL Server中,这些语句生成相同的计划。
与流行的观点相反,在甲骨文中也是如此。
Oracle中的SYS_GUID()
是一个计算密集型函数。
在我的测试数据库中,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(*)
的参数)
发布于 2009-08-03 10:45:17
显然,COUNT(*)
和COUNT(1)
将返回相同的结果。因此,如果其中一个比另一个慢,这实际上是由于优化器的错误。由于这两种形式在查询中都非常频繁地使用,因此DBMS允许此类错误保持不被修复是没有意义的。因此,您会发现,在所有主要的SQL DBMS中,这两种形式的性能(可能)是相同的。
https://stackoverflow.com/questions/1221559
复制相似问题