SELECT COUNT(*) 为什么在 InnoDB 大表上特别慢？优化方案对比

count(*)在InnoDB大表上会全表扫描，因其不维护精确行数，需遍历聚簇索引叶子节点逐行计数，即使有主键也不走覆盖索引，导致大量I/O。

为什么 COUNT(*) 在 InnoDB 大表上会全表扫描？

InnoDB 没有维护精确的行数统计，COUNT(*) 默认不走索引（哪怕有主键），而是遍历聚簇索引的 B+ 树叶子节点——本质是逐行读取记录。即使表有 1 亿行、只存 id 和 created_at，也要访问所有叶子页（可能涉及大量磁盘 I/O 或 Buffer Pool 缺页）。

• 不会使用覆盖索引优化（除非显式改写为 COUNT(id) 且 id 是非空主键）
• WHERE 条件存在时，是否走索引取决于条件选择性，但无条件的 COUNT(*) 几乎总触发全索引扫描
• information_schema.tableS.TABLE_ROWS 的值只是估算，来自采样统计，误差可能达 20%～50%

用 COUNT(主键列) 能快一点吗？

不一定快，但有可能触发覆盖索引，减少数据页访问：

• 如果主键是 NOT NULL（如 int PRIMARY KEY），COUNT(id) 和 COUNT(*) 语义等价，且优化器可能选择只扫描主键索引（避免回表）
• 但如果主键是 Nullable（如 INT PRIMARY KEY NULL），COUNT(id) 必须判空，反而可能更慢
• COUNT(1) 和 COUNT(*) 在 mysql 8.0+ 完全等价，优化器不做区分，不会提速

实际验证建议：

EXPLaiN select COUNT(*) FROM t_large;

EXPLAIN SELECT COUNT(id) FROM t_large;

对比 key 和 rows 字段是否一致。

哪些替代方案真正有效？

没有银弹，需按场景选：

• 实时精度要求低（如后台管理页显示“约 XX 万条”）：查 information_schema.TABLES，快但不准
• 需要相对准确 + 可接受秒级延迟：用近实时的汇总表，例如每 5 分钟由事件驱动任务更新 INSERT ... ON DUPLICATE KEY UPDATE count = count + delta
• 写少读多、能接受轻微延迟：在业务写入路径中维护 redis 计数器（INCRBY / DECRBY），注意事务一致性（推荐用 WATCH + lua 或应用层补偿）
• 纯读场景且允许误差：用 SHOW TABLE STATUS LIKE 't_large' 中的 Rows 字段（仍是估算）

不要用 SELECT COUNT(*) FROM t_large USE INDEX (PRIMARY) 强制索引——InnoDB 本来就会用主键索引，加提示无意义，还可能干扰优化器。

最容易被忽略的性能陷阱

• AUTOCOMMIT=OFF 下执行 COUNT(*)，会持有 MVCC 读视图直到事务结束，导致 purge 线程阻塞、undo 表空间膨胀
• 带 WHERE 的 COUNT(*) 如果条件字段没索引，会先全表扫描再过滤，比无条件还慢
• 分库分表后直接 COUNT(*) 跨多个物理表，中间件（如 ShardingSphere）默认合并结果，网络和 CPU 开销陡增
• 使用 pt-table-checksum 或备份工具期间，大表 COUNT(*) 可能加剧锁竞争和复制延迟

真实线上环境里，一个未加限制的 COUNT(*) 查询卡住 30 秒以上，往往不是因为“SQL 写得不够好”，而是它暴露了统计需求与存储引擎能力之间的根本错配。