当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL COUNT(*) 总数查询变慢怎么办：从扫描行数到汇总表的完整治理流程

MySQL COUNT(*) 总数查询变慢怎么办：从扫描行数到汇总表的完整治理流程

来源：17golang原创 2026-06-15 15:46:13 0浏览收藏

业务列表页经常会遇到一个很隐蔽的性能问题：数据明细查询已经分页了，但页面还是慢。继续看 SQL，才发现真正拖住页面的是另一个看起来很简单的语句：

SELECT COUNT(*)
FROM orders
WHERE tenant_id = 10001
  AND status = 'paid'
  AND created_at >= '2026-06-01'
  AND created_at

这篇文章不只讲“加索引”三个字，而是把 COUNT 总数慢的治理流程完整走一遍：先明确边界，再看扫描行数，再决定用联合索引、缓存总数，还是用汇总表。读完后，你可以把它当成一张排查路线图。

目标和边界：我们要解决哪一种 COUNT 慢

先把边界定清楚。本文讨论的是“带筛选条件的列表总数查询”，常见于后台订单、日志、用户、工单、账单列表。它的特点是：明细查询分页很快，但总数查询要扫描大量行。

不在本文重点里的情况包括：单表全量 COUNT 的存储引擎差异、离线数仓统计、跨库聚合报表。那些场景需要另一套方案。这里我们先把目标定成一句话：

让业务列表页在可接受的准确度和延迟范围内，稳定拿到总数。

我的推荐顺序是：先确认查询条件，再看扫描行数，然后评估索引是否能缩小范围。如果仍然慢，再看业务是否允许缓存总数或使用汇总表。这个顺序很重要，因为缓存和汇总表会引入一致性成本，不能拿来掩盖一个明显缺索引的查询。

一条列表页请求通常会拆成两类 SQL：查当前页数据，以及查总数。COUNT 慢的时候，我们先看它的筛选条件是否稳定，再看 MySQL 为了得到这个总数到底扫了多少行。

MySQL COUNT 总数慢的列表请求到扫描行数流程图

到这一步不要急着加索引。先把真实 SQL 从日志里拿出来，确认它是不是每次都带着租户、状态、时间范围等条件。如果业务代码里有很多可选筛选项，先选出最常见、最影响性能的组合。

SELECT COUNT(*)
FROM orders
WHERE tenant_id = 10001
  AND status = 'paid'
  AND created_at >= '2026-06-01'
  AND created_at

这一阶段的检查点很简单：你能不能拿同一条 SQL 在测试环境或影子库里复现慢。如果不能复现，说明还需要补齐数据量、参数或统计信息，否则后面的优化容易跑偏。

COUNT 慢的核心通常不是“COUNT 函数慢”，而是 MySQL 为了满足 WHERE 条件需要扫描太多记录。先看执行计划：

EXPLAIN
SELECT COUNT(*)
FROM orders
WHERE tenant_id = 10001
  AND status = 'paid'
  AND created_at >= '2026-06-01'
  AND created_at

重点看这几个字段：

如果 rows 接近表总行数，而列表条件又很常见，说明它不是偶发慢，而是结构性慢。下一步才是设计索引。

对于上面的条件，一个常见的联合索引可以这样考虑：

CREATE INDEX idx_orders_tenant_status_time
ON orders (tenant_id, status, created_at);

为什么顺序这样放？tenant_id 通常是等值条件，可以先缩小租户范围；status 也是等值条件；created_at 是范围条件，放在后面更适合按时间区间过滤。索引设计不是背公式，而是让最稳定、选择性较高的条件先减少扫描范围。

如果 COUNT 只需要判断满足条件的记录数量，并且索引本身已经包含过滤所需列，MySQL 就有机会少访问数据行。这类场景可以关注 Extra 里是否出现 Using index，它说明查询可以更多依赖索引完成。

如果加了合适索引仍然慢，或者这个总数被非常高频地访问，就要进入第二层方案：缓存或汇总表。二者不是谁更高级，而是适合不同业务边界。

MySQL COUNT 慢查询的联合索引缓存总数和汇总表选择流程图