能提速，但必须满足where字段、count目标列、索引结构三者严格匹配；否则explain中不显示using index，索引无效。count(*)和count(1)必走主键索引，无法覆盖；仅count(列)在该列not null且索引包含该列时才可能触发覆盖索引。
能提速，但必须满足三个硬条件：WHERE字段、COUNT目标列、索引结构三者严格匹配；否则EXPLAIN里看不到Using index，就只是白建索引。
为什么COUNT(*)几乎不可能走覆盖索引
因为COUNT(*)要统计行数，MySQL必须确认“这一行确实存在且可见”，而二级索引不保证每条记录都完整——比如某行只在主键索引里有，但没被某个二级索引覆盖，那用该索引扫描就会漏掉。所以InnoDB默认走主键索引（聚簇索引）做全扫描，哪怕你建了INDEX idx_a ON t(a)，COUNT(*)也不会用它。
-
COUNT(*)→ 必扫主键索引，无法被任何二级索引覆盖 -
COUNT(1)→ 行为同COUNT(*)，一样扫主键 -
COUNT(col)→ 只统计col非NULL的行，这时才可能走覆盖索引
COUNT(col)走覆盖索引的实操要点
只有当col上有非空约束（NOT NULL），且你建的索引包含col，并且查询不含其他需要回表的字段时，才可能触发Using index。
- 确保
col定义为NOT NULL，否则MySQL得回表判断是否为NULL - 索引只需包含
col本身即可，例如：CREATE INDEX idx_status ON orders(status); - 查询必须是纯
COUNT(col)，不能带WHERE以外的复杂逻辑，比如HAVING或子查询 - 如果加了
WHERE，索引得同时覆盖过滤字段和col，例如：SELECT COUNT(id) FROM users WHERE deleted = 0，索引应为(deleted, id)
EXPLAIN里怎么确认真用了覆盖索引
别信名字，只看Extra列：
- 出现
Using index→ 真覆盖，只读索引页 - 出现
Using index condition→ 仅索引下推，仍要回表取值 - 出现
Using where或空白 → 没覆盖，必然回表 -
type为index或range是必要条件，但不充分；ALL说明连索引都没走
示例：EXPLAIN SELECT COUNT(status) FROM orders WHERE user_id = 123; 如果索引是(user_id, status)，Extra显示Using index才算成功；若索引是(user_id)单列，哪怕status是NOT NULL，也会回表，Extra是Using where。
大表统计别死磕精确COUNT，先想业务能不能妥协
覆盖索引对COUNT的加速效果，在千万级表上通常也就从3秒降到0.8秒——提升明显，但远不如缓存或近似值方案来得彻底。
- 运营后台查“总用户数”？用
SHOW TABLE STATUS LIKE 'users'拿近似值，毫秒返回 - 订单状态统计？维护一张
counter表，用INSERT ... ON DUPLICATE KEY UPDATE实时更新 - 高并发接口要总数？Redis里存
orders:count，写DB时同步+1/-1 - 真要精确+实时+大表？覆盖索引只是起点，不是终点；必须配合分区、物化视图或异步汇总
最易被忽略的一点：覆盖索引只解决I/O瓶颈，不解决锁竞争。如果COUNT查询频繁且并发高，即使走索引，也可能因共享锁阻塞写操作——这时候加索引反而成了新瓶颈。
