MyISAM的COUNT(*)是O(1)因.MYI文件头缓存行数，而InnoDB必须按ReadView逐行判断可见性，无全局精确计数；SHOW TABLE STATUS的Rows仅为估算值，误差可达±40%～50%，不可用于强一致场景。
因为InnoDB必须逐行判断可见性，而MyISAM直接读磁盘元数据里的固定值——这不是配置或SQL写法问题，是MVCC和事务隔离机制决定的硬约束。
MyISAM的COUNT(*)为什么是O(1)操作
MyISAM在.MYI索引文件头里存着一个4字节整数，每次INSERT/DELETE都会原子更新它。执行SELECT COUNT(*) FROM t时，MySQL根本不去碰数据页，只读那个固定偏移量的值。
- 这个快法只适用于无
WHERE条件的场景；一旦加了WHERE status = 1，MyISAM也得走索引扫描，速度立刻掉下来 - 不支持事务，多个并发写入可能导致计数短暂不一致（比如事务B插入未提交，事务A查不到这行）
- 表级锁下，一个长
UPDATE会阻塞所有后续COUNT(*)，QPS可能断崖下跌
InnoDB的COUNT(*)为什么必须全索引扫描
InnoDB没有全局行数缓存，不是“懒得存”，而是MVCC让“当前有多少行”本身就成了动态问题。同一时刻，三个事务看到的行数可能完全不同：
- 事务A启动后，事务B插入但未提交 → A看不到这行
- 事务C在A之后启动、B提交后插入并提交 → C能看到B的行，但A仍看不到
- 所以InnoDB只能按当前事务的
ReadView，一行行调用row_search_mvcc判断是否可见
这个过程实际是轻量级快照读：优化器会选体积最小的索引（比如INDEX(status)比主键索引短），遍历其叶子节点，对每条记录回查聚簇索引获取DB_TRX_ID和DB_ROLL_PTR，再比对事务ID列表——CPU和锁开销都在这儿。
SHOW TABLE STATUS LIKE 't'返回的Rows能信吗
不能用于业务逻辑。这个值来自InnoDB的采样估算（默认扫描约10个数据页），官方文档明确说误差可达±40%～50%，尤其在大批量DELETE后或数据分布严重倾斜时更不准。
- 它只适合两类场景：运维监控趋势（比如发现
table_rows突降30%，提示可能误删）、后台报表类需求（用户看到“约2.3万条”就足够） - 别用它做分页总数、库存校验或触发告警阈值——这些地方必须强一致，就得绕开全表扫描
真正想让InnoDB的COUNT(*)快起来，得放弃“实时精确”
没有银弹，只有折中。如果你的应用能接受最终一致性，外部维护计数器是最实用的解法；如果必须强一致，就得在写入路径上加成本。
- 写时维护：建一张
counter_table（table_name VARCHAR(64),cnt BIGINT），在业务代码里或用TRIGGER同步增减，注意触发器里不能写复杂逻辑，否则拖慢主表写入 - 如果只统计带条件的行（如
COUNT(*) WHERE status=1），给status加覆盖索引：INDEX(status)或INDEX(status, id)，让InnoDB只扫二级索引即可 - 别迷信
EXPLAIN SELECT COUNT(*) FROM t里显示type: index就万事大吉——如果key列是NULL，说明连最小的二级索引都没有，只能走聚簇索引，I/O开销会翻倍
最常被忽略的一点是：哪怕你只为COUNT(*)单独建一个单字段索引（比如INDEX(created_at)），只要它比主键索引小，InnoDB就会优先扫它——这个取舍在千万级以上表上效果立竿见影。
