innodb的count(*)必须扫描索引树，因其无全局行数缓存，需通过快照读遍历索引叶子节点并逐行判断mvcc可见性，优化器选最窄索引以减少i/o。
为什么InnoDB的COUNT(*)必须扫描索引树
InnoDB没有全局行数缓存，COUNT(*)不是查一个数字，而是做一次轻量级快照读——它要遍历某个索引树的所有叶子节点，对每一行调用row_search_mvcc判断是否对当前事务可见。这个过程无法跳过任何节点，因为MVCC要求“按版本链逐行评估”，哪怕只差一行，结果就可能不同。
优化器会选代价最小的索引树来扫，比如表有KEY idx_status(status)和PRIMARY KEY id，而status是TINYINT类型，那它大概率选idx_status——不是因为它“更快”，而是因为它的B+树更窄、页更少、I/O更低。
- 即使只有主键索引，也会扫聚簇索引叶子节点（即全表数据页）
- 如果存在多个非空二级索引，优化器优先选字段最短、重复值最多的那个（例如
TINYINT比VARCHAR(255)优） - 扫描不等于回表：它只读索引字段值，不取整行记录，所以不触发溢出页（
TEXT/BLOB）加载
COUNT(*)和COUNT(id)在InnoDB里真有区别吗
语义上没区别，但执行路径可能不同。当id是NOT NULL PRIMARY KEY时，COUNT(id)可被优化为只扫主键索引，且跳过空值检查；而COUNT(*)始终走标准快照读流程，兼容所有列定义。
但如果id允许为NULL（如INT PRIMARY KEY NULL），COUNT(id)反而多一步判空操作，实际更慢；COUNT(1)在MySQL 8.0+与COUNT(*)完全等价，优化器不做任何特殊处理。
- 别迷信“
COUNT(1)比COUNT(*)快”——这是MySQL 5.6之前的过时经验 -
COUNT(主键列)仅在主键明确NOT NULL时才可能触发覆盖索引优化 - 加了
WHERE之后，是否走索引取决于条件选择性，和COUNT写法无关
为什么information_schema.TABLES.TABLE_ROWS不能当真
这个值来自InnoDB的采样统计（INFORMATION_SCHEMA视图背后调用dict_table_get_n_rows），不是实时计算，也不保证事务一致性。官方文档明示误差可达40%～50%，尤其在大表频繁增删后，采样点可能长期未更新。
它适合做容量预估或告警阈值参考，但绝不能用于分页总数、库存校验、审计对账等强一致性场景。你看到的1048576，真实行数可能是720000或1430000。
-
SHOW TABLE STATUS LIKE 'users'返回的Rows字段，底层就是查TABLE_ROWS - 该值不会因单条
INSERT立即刷新，通常依赖后台线程周期性采样 - 在低频写入表上相对准些，高并发写入+长事务下误差会指数级放大
真正卡住你的从来不是“怎么扫”，而是“要不要扫”
所有试图靠改写COUNT(*)来提速的尝试，本质都在绕开一个事实：你要的不是一个数字，而是一个带事务边界的逻辑断言。只要业务还要求“此刻我看到的准确行数”，InnoDB就只能扫。
更现实的解法是把问题移出数据库：前端用游标分页替代LIMIT OFFSET，后台用异步任务维护计数表，监控告警用采样值+波动率双指标。硬扛COUNT(*)，等于让OLTP引擎干OLAP的活。
最容易被忽略的一点：COUNT(*)本身不锁表，但它会拉长一致性读视图的生命周期，间接拖慢其他查询——这不是慢，是传染性延迟。
