MySQL COUNT 优化实战：大表分页总数不要每次全量统计

后台列表常见一个小细节：页面底部显示“共 1234567 条”。业务同学觉得这只是一个数字，开发同学也常常顺手写一条 COUNT(*)。但当订单表、日志表、流水表变大后，这个总数统计可能比列表查询本身还慢。

本文用订单后台分页做例子，聊聊 MySQL 大表里 COUNT(*) 为什么会拖慢接口，以及如何根据业务场景选择精确统计、缓存总数、异步汇总表或弱化展示。

摘要

本文会完成四件事：识别分页总数统计的性能风险、区分必须精确和可以近似的场景、给出缓存和汇总表方案、整理上线前检查清单。适合正在维护 MySQL 后台列表、报表检索和运营查询的开发者阅读。

适合人群

• 后台列表页越用越慢，怀疑总数统计拖后腿的后端同学。
• 需要处理订单、日志、流水、工单等大表分页查询的开发者。
• 想把“每次查准总数”改成“按场景选择统计策略”的团队。

目录

• 为什么 COUNT 可能比列表查询还慢
• 先判断业务到底需不需要精确总数
• 方案一：条件明确时让索引帮忙
• 方案二：缓存总数，降低重复统计
• 方案三：异步汇总表，服务报表场景
• 常见坑和总结

为什么 COUNT 可能比列表查询还慢

先看一个常见后台订单列表：

SELECT id, order_no, amount, status, created_at
FROM orders
WHERE status = 1
ORDER BY created_at DESC
LIMIT 20;

SELECT COUNT(*)
FROM orders
WHERE status = 1;

第一条 SQL 只取 20 行，如果有合适索引，通常很快。第二条 SQL 要统计符合条件的全部行数，可能需要扫描大量索引记录。数据量越大、筛选条件越宽，统计成本越明显。

更麻烦的是，很多页面每次刷新、翻页、切换筛选条件都会重新统计总数。用户感受到的是“翻页慢”，数据库承担的是“反复数大表”。

先判断业务到底需不需要精确总数

优化前先问一个问题：这个总数必须实时精确吗？不同场景答案不一样。

• 财务结算、审计报表：通常需要精确，甚至要和导出结果一致。
• 运营后台列表：很多时候只需要知道大概规模，或者第一页显示即可。
• 日志检索：更适合展示“已找到很多条”，不一定要给精确总数。
• 用户端搜索：可以弱化总数，优先保证结果返回速度。

总数策略可以按下面的决策路径来选：

方案一：条件明确时让索引帮忙

如果业务确实需要精确总数，第一步仍然是让筛选条件走合适的索引。例如按状态和创建时间统计：

SELECT COUNT(*)
FROM orders
WHERE status = 1
  AND created_at >= '2026-06-01 00:00:00'
  AND created_at 

可以考虑建立联合索引：

ALTER TABLE orders
ADD INDEX idx_status_created (status, created_at);

这里的重点不是“所有 COUNT 都加索引”，而是让高频筛选条件有稳定访问路径。上线前要用真实参数看扫描行数，而不是只在小数据表上验证。

方案二：缓存总数，降低重复统计

如果总数允许短时间不完全实时，可以缓存统计结果。比如同一组筛选条件 30 秒内重复访问时，直接返回缓存值。

count:orders:status=1:month=202606 -> 582031
ttl: 30s

缓存适合这些场景：

• 同一页面被多人反复打开。
• 筛选条件比较固定，例如状态、日期、门店。
• 业务可以接受几十秒级延迟。

缓存不是为了让数字永远准确，而是为了避免短时间内重复扫同一批数据。页面可以加上“约”或弱化总数展示，减少用户对实时精确的误解。

方案三：异步汇总表，服务报表场景

如果统计维度稳定，例如每天每个状态的订单数量，可以维护一张汇总表。

CREATE TABLE order_daily_stats (
    stat_date DATE NOT NULL,
    status TINYINT NOT NULL,
    total_count BIGINT NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (stat_date, status)
);

查询时直接读汇总表：

SELECT SUM(total_count)
FROM order_daily_stats
WHERE status = 1
  AND stat_date >= '2026-06-01'
  AND stat_date 

这种方式适合报表和运营统计。缺点是需要额外维护汇总任务，并处理延迟、重跑、补数和校验。好处是把高频大表统计从在线接口里拆出去。

接口层也要配合降级

有些页面可以把列表数据和总数拆开返回：先返回当前页，再异步补总数。如果总数查询超时，不影响主列表展示。

{
  "items": [],
  "total": null,
  "total_status": "counting"
}

对于用户来说，先看到数据比等待一个精确数字更重要。对于数据库来说，主查询和统计查询拆开后，也更容易做超时、缓存和熔断。

上线前检查清单

1. 列出所有后台列表里的 COUNT(*) 查询。
2. 标记哪些总数必须实时精确，哪些可以缓存或弱化。
3. 对高频精确统计跑执行计划，观察扫描行数。
4. 给重复访问的统计结果加短 TTL 缓存。
5. 对报表类统计建立汇总表或离线任务。
6. 总数查询设置超时，避免拖垮主列表接口。

常见坑

• 所有页面都默认查精确总数。 很多页面只是为了分页展示，不一定需要实时精确。
• 缓存 key 设计太粗。 不同筛选条件必须进入 key，否则会返回错总数。
• 汇总表没有校验。 异步统计要有重跑和对账机制，不能只写一次任务。
• 总数查询没有超时。 一旦统计变慢，可能拖住整个接口。

总结

MySQL 大表分页总数优化的核心，是不要把所有 COUNT(*) 都当成必须实时精确的查询。精确场景要让索引帮忙，重复访问可以缓存，报表场景适合汇总表，用户端列表可以弱化或异步返回。先把业务对“总数”的真实要求问清楚，数据库压力往往就能少一大截。