"SELECT COUNT(列)"比"SELECT COUNT(*)"更快/更慢吗？

Question

我在MSSQL2008中运行这样的查询:

select count(*)
from t1
inner join t2 on t1.id = t2.t1_id
inner join t3 on t1.id = t3.t1_id 

假设t1.id有一个NOT NULL约束.因为它们是内连接并且t1.id永远不能为null,所以使用count(t1.id)而不是count(*)应该产生完全相同的最终结果.我的问题是:性能是否相同？

我也想知道联接是否会影响这个.我意识到添加或删除连接会影响性能和结果集的长度.假设在不更改连接模式的情况下,您设置count为仅定位一个表.会有什么不同吗？换句话说,这两个查询之间是否存在差异:

select count(*)    from t1 inner join t2 on t1.id = t2.t1_id 
select count(t1.*) from t1 inner join t2 on t1.id = t2.t1_id 

MySQL中的COUNT(id)与COUNT(*)为MySQL回答了这个问题,但是我找不到具体的MS-SQL答案,而且我找不到任何考虑join因素的东西.

注意:我试图在Google和SO上找到这些信息,但很难弄清楚如何说出我的搜索.

Answer 1

我尝试了一些SELECT COUNT(*) FROM MyTable与SELECT COUNT(SomeColumn) FROM MyTable各种大小的表相对应,并且SomeColumn曾经是一个聚类键列,一旦它在非聚集索引中,一旦它在没有索引的情况下.

在所有情况下,对于所有大小的表(从300,000行到1.7亿行),我从未看到速度和执行计划方面的任何差异 - 在所有情况下,COUNT通过执行聚簇索引扫描来处理 - >即扫描整个表格,基本上.如果涉及非聚集索引,那么扫描就在该索引上 - 即使在执行时也是如此SELECT COUNT(*)!

在速度或方法方面似乎没有任何差别如何计算 - 计算全部,SQL Server只需扫描整个表 - 期间.

测试是在SQL Server 2008 R2 Developer Edition上完成的

Answer 2

select count(*)当它尝试获取所有内容时会变慢。指定列（PK 或任何其他索引列）将加快速度，因为查询引擎提前知道它正在查找什么。它还将使用索引而不是违背表。