别再用 SELECT COUNT(*) 数大表了：InnoDB 全表扫描的代价与三种替代

一、现象：一个"数数"接口把从库拖到 9 秒

先说结论：在 InnoDB 里，SELECT COUNT(*) FROM t 不是"数个数"，而是全表扫描——它要顺着聚簇索引把整张表的行一条条走一遍才能得出一个数。

我们内部有个"资产总览"后台，首页要展示 inventory 表的总行数。这张表 3800 万行，单行约 200 字节，整张表约 7.6GB。以前用 SELECT COUNT(*)，日常 800ms 左右大家没当回事；直到某天主从切换后，从库上这条 SQL 的 P99 直接拉到 9.3 秒，把其它读请求全堵住，值班同学以为是从库挂了，其实是这一个"数数"接口把 IO 打满了。

打比方：COUNT(*) 在 InnoDB 里就像让你数一个鞋柜里有多少双鞋——它不会翻标签，而是把每一双鞋都掏出来看一眼，再看有没有。鞋柜越大，你数得越久。

二、原理：为什么 InnoDB 的 COUNT(*) 这么贵

• InnoDB 没有维护一个"行数计数器"。这和 MyISAM 不同——MyISAM 表头存了行数，COUNT(*) 是 O(1)；InnoDB 因为 MVCC 多版本，同一时刻不同事务看到的行数不一样，所以没法存一个固定数字，只能现数。
• 关键机制：COUNT(*) 走二级索引最小宽度索引（MIN_LENGTH），但仍要把索引叶子节点全部遍历一遍，逐行判断可见性（MVCC 下还要看 undo 版本）。所以它的耗时和表行数成正比，是 O(N)。
• 更坑的是：即便表上没有任何 WHERE，优化器也用不上覆盖索引"免回表"的红利——它本来就不回表，它只是把整棵 B+ 树叶子扫一遍。表越大、undo 越多，越慢。
• 主从切换后从库上这条 SQL 变慢，是因为从库通常 buffer pool 更小、且要承担回放日志的 IO，全表扫描这种"大吞吐低命中"的查询在从库上尤其致命。

三、具体做法：三种替代（可复现）

方案 A：用最小二级索引近似计数，避开大聚簇索引。 如果表有二级索引且行较宽，让它走最窄的那个索引叶子，扫描量更小：

-- 强制走最窄二级索引（假设 idx_biz_no 是最窄的）
SELECT COUNT(*) FROM inventory FORCE INDEX (idx_biz_no);

实测同表 FORCE INDEX (idx_biz_no) 后从 9.3s 降到 1.1s（索引叶子比聚簇叶子小约 40%）。

方案 B：不要"每次都数"，改成"异步缓存计数"。 后台首页的总数，本质是个"概览数"，不需要 100% 精确。用一个物化视图/汇总表，定时任务每 5 分钟刷一次：

-- 汇总表
CREATE TABLE inventory_stat (stat_key VARCHAR(32) PRIMARY KEY, cnt BIGINT, updated_at DATETIME);
-- 定时任务（每 5 min）
REPLACE INTO inventory_stat VALUES ('total', (SELECT COUNT(*) FROM inventory FORCE INDEX (idx_biz_no)), NOW());
-- 首页查询
SELECT cnt FROM inventory_stat WHERE stat_key='total';

首页查询从 O(N) 变成 O(1)，耗时从秒级降到 <1ms，代价是数据最多滞后 5 分钟——对"总览"场景完全可接受。

方案 C：如果只需要"大概有多少"，直接问引擎估算。

SELECT TABLE_ROWS FROM information_schema.TABLES
WHERE TABLE_SCHEMA=DATABASE() AND TABLE_NAME='inventory';

TABLE_ROWS 是统计值，O(1)，但只作"量级"参考（可能差个位数百分比），适合监控、容量评估，别拿来当精确业务数。

四、踩过的坑 / 反直觉

1. COUNT(列名) ≠ COUNT(*)，但很多人以为等价。 COUNT(col) 要判每行 col 是否为 NULL，通常比 COUNT(*) 还慢；而 COUNT(1) 和 COUNT(*) 在 MySQL 里几乎一样，优化器会归一。别为了"省"去写 COUNT(1) 当优化手段。
2. WHERE 命中索引后 COUNT 会快很多，但一旦 WHERE 条件没走索引，就退回全表扫。 我见过有人在 3800 万行的表上加了 WHERE status=1，却忘了 status 没索引，结果比裸 COUNT 还慢（因为多了一层列读取 + NULL 判断）。
3. 别迷信 FORCE INDEX。 如果最窄二级索引其实比聚簇索引还大（比如全是长 varchar），FORCE INDEX 反而更慢。上线前务必 EXPLAIN 看 type 和 rows，别拍脑袋。
4. 主从场景下，把重计数 SQL 打到从库不是"甩锅"，是"引爆炸药"。 从库 IO 余量小，全表扫描这种查询最容易把从库打挂。

五、结论与可复用清单

• InnoDB 的 COUNT(*) 是 O(N) 全表扫描，行数大 = 必然慢，别拿它当"免费操作"。
• 精确计数：走最窄二级索引 FORCE INDEX，先 EXPLAIN 验证。
• 概览计数：用汇总表 + 定时刷新，把 O(N) 变 O(1)，接受分钟级延迟。
• 量级估算：用 information_schema.TABLES.TABLE_ROWS，只参考不精确。
• 上线 checklist：
  • [ ] 表 > 100 万行时，禁止在请求链路里裸 COUNT(*)
  • [ ] 任何 COUNT 都 EXPLAIN 看 rows 预估
  • [ ] 区分"精确数" vs "概览数"，概览数走缓存
  • [ ] 重查询别打到 IO 余量小的从库
  • [ ] COUNT(列名) 比 COUNT(*) 更慢，无 NULL 需求时别用

一句话总结：别把"数数"当免费的事——在 InnoDB 里，数 3800 万行，和扫 7.6GB 数据是一回事。