innodb的count(*)本质是带mvcc可见性判断的全索引扫描，必须基于当前事务readview逐行验证，无法预存总数；即使走最小二级索引，仍为o(n)时间复杂度，这是事务隔离级别的必然代价。
InnoDB 的 COUNT(*) 本质是带可见性判断的索引扫描
不是“没优化”，而是事务语义决定了它必须这么做。InnoDB 在执行 COUNT(*) 时，不会读取任何预存总数，而是基于当前事务的 ReadView，逐行判断每条记录是否对该事务可见——这一步无法跳过，否则就破坏了可重复读（RR）隔离级别。
常见错误现象：EXPLAIN SELECT COUNT(*) FROM t 显示 type: index，但 key 列为空，说明在扫主键索引（聚簇索引），I/O 开销极大；若表有小字段的二级索引（如 INDEX idx_status (status)），优化器会自动选它来遍历，因为叶子节点只存索引列 + 主键值，体积更小。
- 即使写成
COUNT(1)或COUNT(id)，MySQL 8.0+ 优化器也等价重写为COUNT(*)，性能无差别 - 没有二级索引时，
COUNT(*)只能扫聚簇索引，等于读全表数据，不是“只读索引” - buffer pool 命中率低时（如刚重启、大表首次查），物理读激增，可能触发超时（MySQL 8.0.18 已知问题）
MyISAM 的 COUNT(*) 真的是 O(1)，但它不解决一致性问题
MyISAM 在 .MYI 文件头固定偏移处存了一个叫 rec_count 的 4 字节整数，每次 INSERT/DELETE 都原子更新。执行无 WHERE 的 COUNT(*) 时，MySQL 根本不访问数据页，只读这个值。
但这只是“快”，不是“对”。它的代价是：表级锁下，一个长 UPDATE 会阻塞所有 COUNT(*)；事务 B 插入未提交，事务 A 就查不到这行 → 计数短暂不一致。所以它只适合无并发写、不要求事务语义的场景（比如静态配置表）。
- 加了
WHERE status = 1，MyISAM 同样要走索引扫描，O(1) 优势立刻消失 -
SHOW TABLE STATUS LIKE 't'返回的Rows字段，是 InnoDB 的采样估算值（默认约 10 个页），误差常达 ±40%～50%，绝不能用于分页总数或库存校验
别指望“换索引”让 COUNT(*) 变快，得换思路
建索引只能降低 I/O（选最小索引树遍历），但无法绕过“逐行可见性判断”这个核心开销。真正影响响应时间的是：是否必须强一致、能否接受最终一致、业务是否允许写时维护。
- 能接受最终一致 → 外部维护计数器：用
counter_table表 + 应用层增减，或用轻量 TRIGGER（注意别在触发器里做远程调用） - 必须强一致且 QPS 不高 → 把
COUNT(*)拆到写入路径：插入/删除后同步更新缓存（如 Redis）并设 TTL，读时先查缓存，失效再回源 - 千万级以上大表且需实时总数 → 放弃
COUNT(*)，改用近似统计（如 HyperLogLog）或物化视图（MySQL 8.0.23+ 支持不可变聚合表）
最常被忽略的一点：COUNT(*) 慢不是 bug，是 MVCC 的必然代价
很多人查完执行计划、建完索引、调完 buffer pool 还是慢，就怀疑配置或版本问题。其实只要还在用 InnoDB + RR 隔离级别，COUNT(*) 就不可能是 O(1)。这不是 MySQL 实现得差，而是事务安全和查询速度之间的硬约束。
如果你的接口因 COUNT(*) 超时，优先检查是否真需要这个精确总数——列表分页往往只需要“是否有下一页”，用 LIMIT 21 查 21 条比查总数 + LIMIT 20 更快也更可靠。
