count(*) 看起来只是统计行数，但在 InnoDB 里它不等于读一个全局计数器。因为 MVCC 存在，不同事务在不同 ReadView 下看到的可见行数可能不同。
这也是大表 count 变慢的根本原因：精确实时计数必须为可见性付费。MySQL 往往需要扫描某个索引，逐行判断当前事务能不能看见，再累计结果。
先把机制边界说清楚
InnoDB 支持 MVCC，不同事务在不同 ReadView 下看到的可见行数可能不同。因此它不能像某些简单存储结构那样维护一个对所有事务都正确的全局行数。count(*) 通常需要扫描某个索引，逐行判断可见性并累计。
整体路径
上面这张图先看粗线条：宏观上，count(*) 是一次可见性范围内的聚合。优化器会选择成本较低的索引来扫描，扫描过程中 InnoDB 读取索引记录，结合事务可见性判断是否计入结果。条件越复杂、范围越大，成本越高。
底层流程
底层拆解先看数据结构。「count(*)」至少涉及下面几类结构：
- ReadView：决定当前事务能看见哪些版本。
- 二级索引叶子：常被选择为更窄的扫描路径。
- undo 版本链：必要时用于判断历史版本可见性。
- 聚合计数器：Server 层累计满足条件的行数。
再看完整执行流程：
- Server 层识别 count 聚合。
- 优化器选择扫描路径，通常倾向较小索引。
- 存储引擎逐条读取候选记录。
- 按 MVCC 判断记录是否对当前事务可见。
- Server 层累加并返回结果。
取舍与边界
版本差异上，MySQL 8.0 对优化器和索引统计有增强，但 InnoDB 下 count(*) 仍然受 MVCC 可见性约束。MyISAM 曾经能快速返回无条件 count，是因为它维护表级行数且没有同样的事务可见性语义。
count 的短板是业务经常要求“实时、精确、复杂条件”。这三个要求叠在一起，大表上几乎必然贵。即使走索引，也可能需要扫描大量叶子记录。
典型问题：用机制化例子排查
分页总数问题可以从产品语义开始拆：用户是否真的需要实时精确总数，还是只需要是否还有下一页。语义不同，数据库成本完全不同。
可以落到这些动作：
- 确认产品是否真的需要实时精确总数。
- 能用小索引扫描就不要扫宽索引或整行。
- 高频复杂条件计数改用汇总表、缓存或离线统计。
- 分页优先使用 has_more 或游标，减少每页 count。
收束：count 先问产品语义
count(*) 的难点不是函数，而是事务可见性和产品语义。架构上要敢于区分“必须精确”和“可以近似”。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MySQL」，欢迎关注公众号 「十三Tech」。后续会继续按机制、图解和实战排查这条线更新。
