对计数（*）进行计数（PK）是否有任何性能改进[重复]

Question

是的，我知道这个问题与此线程相似：COUNT(*) vs. COUNT(1) vs. COUNT(pk): which is better?，但这有点不同。

我的前辈说从count(PrimaryKey) 得到结果，假设PrimaryKey 不能是NULL，在某种程度上比做一个普通的count(*) 更快。这是真的吗？

如果这是真的，那么对于所有 RDBMS 来说都是真的吗？可以的话请参考（半）官方文档。

Answer 1

没有。这似乎是一个持续存在的误解，基于语法之间的混淆

SELECT * FROM ...

和

SELECT COUNT(*) FROM ...

在第一种情况下，* 引用所有列，返回这些肯定比返回单个列需要更多资源。在第二种情况下，COUNT(*) 只是“计算所有行数”的简写。错误的信念是COUNT(*) 以某种方式指示数据库引擎检查所有行中的所有列，而COUNT(<pk_field>) 只需要查看一列。

SO 上还有许多其他 cmets 引用 SQL-92 标准，该标准明确指出 COUNT(*) 应该只引用表的基数，因此，至少在理论上，数据库引擎应该能够识别并优化它。

据我所知，在这两种情况下，大多数数据库引擎（Postgres、Oracle、MySQL InnoDB）只会执行索引扫描来计算行数。如果您指定 PK，则将使用该索引；如果你只使用COUNT(*)，那么查询规划器会选择一个跨越整个表的索引*，但性能应该是相同的。

我能找到的唯一例外是 MySQL 和 MyISAM 表——这些表缓存行数，所以COUNT(*) 非常快。但是，查询计划器也将COUNT(<field>)（其中<field> 是任何非空列）识别为对完整表大小的请求，并且在这种情况下也使用缓存。 (source) 同样，性能没有差异。

_{* 理论上，如果你没有这样的索引，那么COUNT(*) 会很慢，但在这种情况下，COUNT(<pk>) 就不可能了}

Answer 2

这并不重要，有几个原因。首先，COUNT(1) 和 COUNT(*) 这两个符号都是错误的语法。考虑关于SUM 聚合的相同问题。哦，SUM(*) 没有任何意义；为什么？因为，求和是赋值的迭代执行

for( int columnValue : columnList )
   currentSum = currentSum + columnValue;

而对于COUNT 聚合它看起来像这样

for( Tuple t : tupleList )
   currentSum = currentSum + 1;

因此，COUNT 聚合根本不应该有任何参数！

然后，有各种各样的语法怪癖，例如count distinct。这只是表明 SQL 设计者的无能，他们试图将两个连续的操作（选择不同的元组，然后聚合）压缩到一个操作中。

这无关紧要的第二个原因是，在实践中您会遇到无数性能不佳的查询，COUNT(1) 与 COUNT(*) 从来都不是瓶颈。