count(*)在innodb中非o(1)，因mvcc需扫描索引逐行判断可见性；优化关键在于避免实时统计，而非改写sql。
COUNT(*) 在 InnoDB 表上不是 O(1)，必须扫描索引，数据量越大越慢——这不是写法问题，是引擎设计决定的；优化核心不是“怎么写得更快”，而是“能不能不实时 COUNT”。
为什么 COUNT(*) 在 InnoDB 里必须扫索引
InnoDB 支持 MVCC，同一时刻不同事务看到的行数可能不同，所以无法像 MyISAM 那样缓存一个固定值。它必须遍历某个索引（通常是主键）来逐行判断可见性并累加。哪怕表有 1000 万行、主键只有 8 字节，也要读取至少 1000 万次索引节点。
常见错误现象：
- 执行
SELECT COUNT(*) FROM orders卡住 3–8 秒，EXPLAIN显示type: index且rows接近总行数 - 加了
WHERE status = 'paid'后更慢，但status列明明有索引——其实是索引选择性差或没走覆盖索引 -
key字段为NULL，说明压根没走索引，退化成全表扫描
带 WHERE 条件的 COUNT(*) 性能崩塌点
一旦加条件，优化器是否能用上索引、是否需要回表、是否触发临时表，全看条件写法和索引结构。
容易踩的坑：
-
WHERE DATE(created_at) = '2026-09-01'：函数包裹列，created_at索引失效 -
WHERE user_id IN (SELECT id FROM users WHERE region = 'CN')：未重写为 JOIN，子查询可能反复执行 -
WHERE JSON_CONTAINS(meta, '"shipped"')：JSON 字段无有效索引支持，强制全表扫描 -
Extra中出现Using temporary或Using filesort：哪怕只是 COUNT，JOIN 或子查询引入排序也会陡增开销
实操建议：
- 用
EXPLAIN看type是否为range或ref，key是否命中预期索引 - 高频过滤字段组合建索引，例如
INDEX(status, created_at)，让 COUNT 走覆盖索引 - 避免在 WHERE 中对字段做计算或类型转换
绕过 COUNT(*) 的三种落地方式
多数业务场景根本不需要精确、实时的总数。硬扛 SQL 优化不如换物理结构。
Redis 计数器（适合秒级误差可接受）
- 增删操作必须配套
INCRBY/DECRBY，不能用GET + SET模拟原子操作 - Redis 不参与 MySQL 事务，需应用层双写 + 失败补偿（如落日志 + 后台重试）
- 每天凌晨用
SELECT COUNT(*) FROM t全量校准一次，写入SET t:count:backup防宕机丢数
元数据表（适合强一致要求）
- 建表：
CREATE TABLE t_count (name VARCHAR(64) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0) - 高并发写入点别直接
UPDATE ... SET cnt = cnt + 1，改用INSERT INTO t_count VALUES ('order_total', 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1降低锁粒度 - 批量导入时先算出 Δ，再单条
UPDATE t_count SET cnt = cnt + ?，别循环 N 次
SHOW TABLE STATUS 近似值（只适用于无 WHERE 的粗略估算）
- 执行快，但
Rows是采样估算值，误差常达 10%–50% - 不支持条件过滤，也不能用于分页总数等需精确值的场景
最容易被忽略的复杂点
真正卡住人的从来不是“怎么写 COUNT”，而是业务逻辑里混着“必须精确”和“其实可以延迟”的需求，却没人拉齐共识。比如分页接口返回 total，前端只用来算页码，用户根本不在意第 1001 页是否存在——这时用 Redis 缓存 5 秒，比优化 SQL 省下 90% 的 DB 压力。而另一些场景，比如财务对账，少计 1 行就是事故。区分清楚“哪类 COUNT 真的不能妥协”，比堆索引或换缓存更重要。
