能，但仅当索引满足“包含所有行可见性判断所需字段”且字段为not null时生效；count(*)可走任意not null索引，count(col)则要求col定义为not null并被索引覆盖。
覆盖索引能加速 COUNT(*) 吗？取决于表结构和查询写法
能，但只在特定条件下生效。MySQL 的 COUNT(*) 本身不读行数据，只统计行数；但如果引擎无法直接从索引中确认“这一行一定存在且未被删除”，它就会退回到聚簇索引（主键）扫描——这时覆盖索引就失效了。关键看是否满足「索引包含所有需要判断行可见性的字段」。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，哪怕建了二级索引也无用；Handler_read_next 值极高，说明在遍历大量索引项甚至回表。
- MyISAM 表天然支持快速
COUNT(*)，因为行数存在磁盘元数据里，跟索引无关 - InnoDB 必须依赖索引扫描，优先选最窄的、不含
NULL的非空索引（比如PRIMARY KEY或NOT NULL的唯一索引） - 如果写的是
COUNT(col)且col允许为NULL，MySQL 必须检查每行该列是否非空，此时只有覆盖该列的二级索引才可能被选中
COUNT(*) 和 COUNT(id) 在覆盖索引下的行为差异
本质区别在于「是否需要判空」。前者只要行存在即可计数，后者必须读取 id 值并判断是否为 NULL。这意味着：即使你建了 INDEX idx_id (id)，若 id 是 NULLABLE，MySQL 仍可能放弃它而扫主键。
使用场景：想用覆盖索引加速统计时，优先保证被统计字段定义为 NOT NULL，尤其是用作 COUNT() 参数的列。
-
COUNT(*)→ 可走任意NOT NULL索引（如INDEX idx_status (status)），只要该索引比主键窄 -
COUNT(id)→ 若id是主键且NOT NULL，优化器大概率直接用主键索引（此时谈不上“覆盖”）；若id是普通列，必须有INDEX idx_id (id)且id定义为NOT NULL才可能触发覆盖 - 性能影响：一个
INT字段的单列索引比主键（可能是BIGINT+ 复合业务字段）小得多，扫描更快，Buffer Pool 压力更低
为什么加了索引，EXPLAIN 却没走？
不是所有索引都适合做统计扫描。MySQL 优化器会估算成本，若它认为全表扫描（即扫聚簇索引）比扫某个二级索引更便宜，就会跳过你建的“覆盖索引”。典型原因包括：索引选择性差、表太小、统计信息过期、或索引字段含大量 NULL。
容易踩的坑：给 status 这种低基数字段（如只有 0/1）建单列索引，期望加速 COUNT(status = 1) —— 实际上优化器发现走这个索引要随机跳转太多页，不如扫主键顺便过滤。
- 先执行
ANALYZE TABLE tbl_name更新统计信息 - 用
SELECT COUNT(*) FROM tbl_name USE INDEX (idx_col)强制指定索引（仅调试用，线上慎用） - 检查
SHOW INDEX FROM tbl_name中的Cardinality，过低说明索引区分度差，不适合作为统计入口 - 避免在索引字段上用函数或表达式，比如
COUNT(IF(status=1,1,NULL))会让索引完全失效
复合索引怎么设计才能支撑 COUNT 类查询？
核心原则：把用于过滤的字段放前面，把用于统计的字段放最后，并确保统计字段 NOT NULL。例如要加速 COUNT(*) WHERE tenant_id = ? AND status = ?，最优索引是 INDEX idx_tenant_status (tenant_id, status) —— 因为前导列过滤后，剩余结果集在索引中是连续存储的，MySQL 可以直接数索引项个数。
注意：这里不需要额外包含主键，因为 COUNT(*) 不需要回表取值；但如果写的是 COUNT(id)，且 id 不在该复合索引里，就会被迫回表，失去覆盖意义。
- 字段顺序不能错：
(status, tenant_id)对WHERE tenant_id = ?就无法使用前缀匹配 - 如果查询带
ORDER BY或LIMIT，索引设计目标会变，覆盖统计不再是首要考虑 - 线上大表加索引务必评估
ALTER TABLE阻塞时间，可考虑ALGORITHM=INPLACE（5.6+）或 pt-online-schema-change
真正难的不是建索引，而是让优化器相信“扫这个索引比扫主键更划算”。很多时候得靠组合手段：调统计信息、压字段为 NOT NULL、控制索引宽度、甚至改写成子查询绕过优化器误判。这些细节一漏，覆盖索引就只是躺在 SHOW INDEX 里的摆设。
