InnoDB中count(*)必须逐行扫描以满足MVCC可见性要求，无法像MyISAM那样直接返回全局行数；它需按当前事务Read View判断每行是否可见并累加，这是语义必需而非性能缺陷。
为什么count(*)在InnoDB里必须逐行扫描
因为InnoDB要满足MVCC（多版本并发控制），同一张表在不同事务里“可见的行数”可能完全不同。比如事务A启动后，事务B插入一行再提交，事务A执行count(*)仍看不到这行——所以InnoDB没法像MyISAM那样存一个全局行数直接返回。它只能按当前事务的Read View，把索引树中每行拉出来判断是否可见，再累加。这不是慢，是必须这么做。
EXPLAIN看不出问题，但实际执行很慢
EXPLAIN对count(*)常显示rows为估算值，甚至标为NULL，容易误判“没走索引”。实际上InnoDB优化器会自动选最小的索引树扫描（比如只存主键的二级索引），但前提是这个索引存在且未被锁住。常见陷阱包括：
- 表只有主键索引，而主键是
BIGINT+ 大字段，导致聚簇索引页密度低、I/O翻倍 - 有二级索引但正在被
ALTER TABLE重建，count(*)被迫退回到扫主键 - 查询期间有长事务持有
MDL锁，阻塞了索引统计路径
并发执行count(*)时结果不一致不是Bug
这是MVCC的正常表现。例如两个事务几乎同时执行select count(*) from order_info where status = 1，只要中间有任意一行status被更新并提交，它们返回的数字就可能不同。这不是数据错乱，而是事务隔离级别的语义保证。如果你需要强一致性计数，说明业务场景本身就不适合用count(*)实时查——该换方案了。
别迷信“加索引就能加速count(*)”
对无WHERE条件的count(*)，索引作用有限：它只是让MySQL少读点数据，但依然要遍历整棵树。真正有效的做法是看访问模式：
- 如果90%的请求都是
count(*) where create_time > '2026-09-01'，那就建(create_time)联合索引，让count(*)能走范围扫描+索引覆盖 - 如果查询带
group by user_id，那count(*)就依赖user_id索引的有序性，而非单纯“有没有索引” - 盲目给大表加
KEY(status)却从不查status单值，只会拖慢写入，对count(*)毫无帮助
count(*)慢从来不是单一SQL的问题，而是暴露了架构层面对“实时精确统计”的错误假设。当它开始影响接口响应或引发连接池打满，就该立刻停掉所有直接查count(*)的代码，转向缓存、汇总表或采样估算——而不是继续调优这条语句。 
