innodb 的 count(*) 必须逐行判断可见性，因 mvcc 和可重复读隔离级别无法缓存全局准确行数；它会选最小二级索引扫描以减少 i/o，而 show table status 的 rows 是估算值，误差大且不一致。
COUNT(*) 在 InnoDB 表上慢，不是你 SQL 写错了，也不是服务器配置低，而是它必须一行行判断可见性——这是 MVCC 和可重复读隔离级别决定的硬约束。MyISAM 能秒出结果，是因为它压根不支持事务，直接返回磁盘元数据里的固定值；而你线上用的 InnoDB，没法这么干。
为什么 InnoDB 的 COUNT(*) 不能缓存总行数
InnoDB 每个事务看到的“当前表有多少行”，取决于它的 ReadView。同一时刻，事务 A 看到 100 万行，事务 B（刚插入一条未提交）可能看到 1000001 行，事务 C（已提交但时间点更早）可能只看到 999999 行。数据库没法存一个“全局准确值”给所有人用。
所以每次执行 COUNT(*)，InnoDB 都得：
- 选一棵索引树（通常是叶子节点最轻的二级索引）遍历
- 对每个叶子节点对应的主键，回表或直接判断该行是否对当前事务可见
- 仅把可见行计入总数
这个过程本质是「带可见性过滤的全索引扫描」，数据量越大，耗时越线性增长。
COUNT(*) 选哪个索引真的有影响
InnoDB 优化器会自动选最小的索引树来扫，但前提是这个索引存在且可用。如果你只有主键索引，那它就只能扫主键 B+ 树（叶子节点存整行），I/O 开销大；如果你建了一个 KEY idx_status (status) 这样的单列二级索引，叶子节点只存 status + 主键，体积可能只有主键索引的 1/5～1/10，COUNT(*) 就会优先扫它。
验证方法很简单：
EXPLAIN SELECT COUNT(*) FROM t;
看 key 列输出的是哪个索引。如果显示 NULL，说明连最小的二级索引都没有，只能走聚簇索引——这就是性能崩掉的第一步。
注意：这个索引不一定要高频查询用得上，纯为 COUNT(*) 建一个单字段索引（比如 id 或 created_at）是常见且有效的取舍。
别信 SHOW TABLE STATUS 返回的 Rows
这个命令快是真快，但它返回的 Rows 字段是采样估算值，官方文档明确说误差可达 40%～50%。它基于随机页抽样统计，不涉及 MVCC 判断，也不保证事务一致性——和 COUNT(*) 解决的是完全不同的问题。
你用它做监控大盘、趋势分析可以，但绝不能用于：
- 分页总数展示（用户看到 “共 1234567 条”，实际查出来只有 80 万）
- 业务逻辑分支判断（比如 “如果用户数
- 财务/审计类强一致场景
一旦误用，后端日志里会出现大量 “总数对不上” 的排查工单。
真正能落地的三种方案，按一致性强度排序
没有银弹，只有权衡。选哪个取决于你的业务容忍度：
-
计数器表 + 事务内维护：建一张
counter表，字段为table_name和row_count，所有INSERT/DELETE必须在同一个事务里更新计数器。强一致，但写放大，且无法处理TRUNCATE或批量导入。 - Redis 缓存 + 异步补偿：应用层在增删后异步更新 Redis 计数，同时监听 binlog 做兜底校正。最终一致，吞吐高，但需额外组件和运维成本。
-
覆盖式定时快照：凌晨低峰期跑一次
COUNT(*)，结果写入一张daily_count_snapshot表供白天查询。延迟 24 小时，但零侵入、零并发风险，适合运营后台类场景。
最容易被忽略的一点：这些方案都不是用来替代 COUNT(*) 的，而是帮你把「实时精确总数」这个需求，从 OLTP 数据库里剥离出去。数据库本就不该承担这种高代价的聚合职责。
