COUNT(*)慢是因为InnoDB必须按事务快照逐行扫描统计，无法读取元数据；即使走索引也要遍历整个索引树，IO量取决于所选索引大小，聚簇索引扫描代价远高于紧凑二级索引。
为什么COUNT(*)走索引却还是慢
因为MySQL的COUNT(*)不是“查元数据”，而是真扫描——哪怕走了索引，也要遍历整个索引树。InnoDB没有MyISAM那种表级行数缓存，每个事务看到的数据版本不同，所以必须按当前隔离级别实际数一遍。关键在于：优化器选哪个索引来扫，决定了IO量大小。如果它选了主键索引（聚簇索引），就得读大量页；如果能选一个更小的二级索引，性能就能明显提升。
如何让COUNT(*)强制走最小二级索引
你不能直接指定索引，但可以“引导”优化器选更优路径：
- 确保表上至少有一个非空、非唯一、体积小的二级索引，比如
status或created_at这类高频过滤字段的单列索引 - 避免在
COUNT(*)语句里加无意义的WHERE条件（如WHERE 1=1），这可能干扰优化器对索引选择的代价估算 - 如果只有主键索引可用，
COUNT(*)就只能扫聚簇索引——此时EXPLAIN中key会显示PRIMARY，rows接近总行数，且type为index - 执行
ANALYZE TABLE orders更新统计信息，防止优化器因过期基数误判而放弃走二级索引
COUNT(1)、COUNT(id)和COUNT(*)有区别吗
在InnoDB下，三者执行计划完全一致，优化器都会等价转为COUNT(*)处理，不校验字段是否为NULL，也不读取字段值。所以别信“COUNT(1)比COUNT(*)快”的说法——那是老版本MySQL或MyISAM的残留认知。真正影响性能的是索引路径，不是括号里的内容。
覆盖索引对COUNT查询有没有用
没用。覆盖索引的价值在于避免回表，而COUNT(*)根本不需要回表——它只关心“有多少行”，不关心行里有什么。给SELECT COUNT(*) FROM orders WHERE status = 'paid'建(status, user_id)联合索引，和只建(status)效果一样；多加的字段只会增大索引体积，拖慢写入，还可能降低选择性。重点永远是：让WHERE条件能高效过滤 + 让优化器愿意用这个索引做全索引扫描。
