asp.net - count(*) 真的很贵吗？

Question

我有一个页面，其中有 4 个选项卡，显示基于不同表格的 4 个不同报告。

我使用 select count(*) from <table> 获取每个表的行数查询并显示选项卡上每个表中可用的行数。结果，每个页面回发都会导致 5 count(*)要执行的查询(4 个用于获取计数，1 个用于分页)和 1 个用于获取报告内容的查询。

现在我的问题是:是count(*)查询真的很昂贵——我应该将行计数(至少是选项卡上显示的行计数)保留在页面的 View 状态中，而不是多次查询吗？

COUNT(*) 次查询的成本有多高？

Answer 1

一般来说，COUNT(*) 成本与满足查询条件的记录数加上准备这些记录所需的时间(取决于底层查询复杂性)成正比。

在处理单个表的简单情况下，通常会进行特定的优化来降低此类操作的成本。例如，从 MySQL 中的单个 MyISAM 表执行没有 WHERE 条件的 COUNT(*) - 这是即时的因为它存储在元数据中。

例如，让我们考虑两个查询:

SELECT  COUNT(*)
FROM    largeTableA a

由于每条记录都满足查询，因此 COUNT(*) 成本与表中的记录数成正比(即与它返回的内容成正比)(假设需要访问行并且没有特定的优化来处理它)

SELECT  COUNT(*)
FROM    largeTableA a
JOIN    largeTableB b
ON      a.id = b.id

在这种情况下，引擎很可能会使用HASH JOIN，并且执行计划将如下所示:

1. 在较小的表上构建哈希表
2. 扫描较大的表，查找哈希表中的每条记录
3. 边计算匹配的数量。

在这种情况下，COUNT(*) 开销(步骤 3)可以忽略不计，查询时间将完全由步骤 1 和 2 定义，即构建哈希表并查找它向上。对于这样的查询，时间将为O(a + b):它并不真正取决于匹配的数量。

但是，如果a.id和b.id都有索引，则可以选择MERGE JOIN，并且 >COUNT(*) 时间将再次与匹配数成正比，因为每次匹配后都会执行索引查找。