一般来说,成本COUNT(*)
成本与满足查询条件的记录数加上准备这些记录所需的时间(这取决于底层查询的复杂性)成正比。
在处理单个表的简单情况下,通常会进行特定的优化以使此类操作变得便宜。例如,COUNT(*)
没有WHERE
条件从单个MyISAM
表中执行MySQL
- 这是即时的,因为它存储在元数据中。
例如,让我们考虑两个查询:
SELECT COUNT(*)
FROM largeTableA a
由于每条记录都满足查询,因此COUNT(*)
成本与表中的记录数成正比(即,与它返回的内容成正比)(假设它需要访问行并且没有特定的优化来处理它)
SELECT COUNT(*)
FROM largeTableA a
JOIN largeTableB b
ON a.id = b.id
在这种情况下,引擎很可能会使用HASH JOIN
,执行计划将是这样的:
- 在较小的表上构建哈希表
- 扫描较大的表,在哈希表中查找每条记录
- 在比赛进行时数数比赛。
在这种情况下,COUNT(*)
开销(第 3 步)可以忽略不计,查询时间将完全由第 1 步和第 2 步定义,即构建哈希表并进行查找。对于这样的查询,时间将是O(a + b)
:它并不真正取决于匹配的数量。
a.id
但是,如果和上都有索引b.id
,则MERGE JOIN
可以选择 并且COUNT(*)
时间将再次与匹配次数成正比,因为每次匹配后都会执行索引查找。