COUNT（*）和COUNT（1）在结果和性能方面是相同的。

在SQL Server中，这些语句产生相同的计划。

与流行的观点相反，在甲骨文公司，他们也是如此。

Oracle中的SYS_GUID（）是一个计算密集型函数。

在我的测试数据库中，t_even是一个包含1000000行的表

此查询：

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（{[[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月

DBA.SE上的类似问题。

编辑，2011年12月

ANSI-92中特别提到了COUNT（*）（查找“标量表达式125”）

案例：a） 如果指定了COUNT（*），则结果是T的基数。

也就是说，ANSI标准认为这是你的意思。由于这种迷信，RDBMS供应商已经优化了COUNT（1）。否则将按照ANSI进行评估

b） 否则，让TX是单列表，即将<value表达式>应用于T的每一行的结果以及消除空值。如果一个或多个空值消除，则引发完成条件：警告-

COUNT（*）和COUNT（1）在结果和性能方面是相同的。

显然，COUNT（*）和COUNT（1）将始终返回相同的结果。因此，如果一个比另一个慢，这实际上是由于优化器错误。由于这两种形式在查询中都使用得非常频繁，所以DBMS不允许这样的错误保持不变是没有意义的。因此，您将发现两种形式的性能（可能）在所有主要的SQL DBMS中都是相同的。

在所有RDBMS中，这两种计数方式在产生什么结果方面是等价的。关于性能，我没有在SQL Server中观察到任何性能差异，但值得指出的是，一些RDBMS，例如PostgreSQL 11，在检查参数表达式的可空性时，COUNT（1）的实现不太理想，如本文所示。

我发现运行以下命令时，1M行的性能差异为10%：

-- Faster
SELECT COUNT(*) FROM t;

-- 10% slower
SELECT COUNT(1) FROM t;