innodb的count(*)必须逐行判断可见性，这是mvcc机制决定的硬约束；myisam则直接读.myi文件头的预存行数，为o(1)操作，但不支持事务且加where后同样需扫描。
InnoDB的COUNT(*)必须逐行判断可见性
这不是配置问题，也不是SQL写法不对，而是MVCC机制决定的硬约束。同一时刻，事务A、B、C可能看到完全不同的行数——因为每条记录都有DB_TRX_ID和DB_ROLL_PTR隐藏字段，InnoDB必须按当前事务的ReadView逐行校验是否可见。这个过程本质是「带可见性过滤的全索引扫描」，CPU和锁开销都在这儿。
MyISAM的COUNT(*)直接读磁盘元数据
MyISAM在.MYI文件头固定偏移处存着一个4字节整数，每次INSERT/DELETE都会原子更新它。执行SELECT COUNT(*) FROM t时，MySQL根本不访问数据页，只读那个值——所以是O(1)操作。
- 这个快法只适用于无
WHERE条件的场景；加了WHERE status = 1，MyISAM也得走索引扫描 - 不支持事务，多个并发写入可能导致计数短暂不一致（比如事务B插入未提交，事务A查不到这行）
- 表级锁下，一个长
UPDATE会阻塞所有后续COUNT(*)，QPS可能断崖下跌
InnoDB优化器选索引有讲究
InnoDB会自动选体积最小的索引树来遍历，但前提是这个索引存在。验证方法很简单：EXPLAIN SELECT COUNT(*) FROM t，看key列输出的是哪个索引：
- 如果显示
NULL，说明连最小的二级索引都没有，只能扫聚簇索引（叶子节点存整行），I/O开销大 - 建一个单列
INDEX(status)，叶子节点只存status + 主键，体积可能只有主键索引的1/5～1/10，COUNT(*)就会优先扫它 - 这个索引不一定要高频查询用得上，纯为
COUNT(*)建一个INDEX(id)或INDEX(created_at)是常见且有效的取舍
SHOW TABLE STATUS的Rows字段不能信
SHOW TABLE STATUS LIKE 't'返回的Rows是采样估算值，官方文档明确说误差可达±40%～50%。它基于随机抽样约10个数据页，不涉及MVCC判断，也不保证事务一致性。
- 适合运维监控趋势（比如发现
table_rows突降30%，提示可能误删）或后台报表类需求（用户看到“约2.3万条”就足够） - 绝不能用于分页总数展示、库存校验、财务/审计类强一致场景——一旦误用，后端日志里会出现大量“总数对不上”的排查工单
- 它和
COUNT(*)解决的是完全不同的问题：一个是快但不准，一个是慢但强一致
innodb_buffer_pool_size，只要业务要求结果对当前事务精确可见，InnoDB就不得不一行行比对ReadView。这时候，与其死磕扫描性能，不如评估能否接受最终一致性——比如用触发器维护counter_table，或者把计数逻辑移到应用层异步更新。
