InnoDB中COUNT(*)默认走主键索引以保证MVCC可见性判断准确，但若存在NOT NULL的二级索引列并配合等值WHERE条件（如WHERE status=1），优化器会优先选择该二级索引实现覆盖扫描，显著减少I/O。
为什么 COUNT(*) 会扫描主键索引而不是更快的二级索引
InnoDB 的 COUNT(*) 默认走主键索引（聚簇索引），因为语义上它要统计“可见行数”，而 MVCC 要求逐行判断可见性——只有主键能保证每行唯一且可定位。但主键索引叶子节点存的是整行数据，体积大、IO 多；而二级索引叶子节点只存主键值 + 索引列，更轻量。
优化器其实**知道**二级索引更小，但它不会主动用二级索引做 COUNT(*)，除非你明确告诉它：“这条路径足够安全”。关键在于：只要 WHERE 条件能命中某个**非空、NOT NULL 的二级索引列**，优化器就可能选它来减少扫描量。
- 例如表有
status字段（NOT NULL）并建了索引KEY idx_status (status)，那么COUNT(*) WHERE status = 1很可能走idx_status，而非全表或主键 - 如果该列允许为
NULL，MySQL 就得回表或额外判断是否为 NULL，反而可能放弃索引 -
COUNT(status)不会走idx_status做覆盖，因为语义要求检查每行status是否为 NULL，必须取值判断
如何强制让 COUNT 走二级索引（且不回表）
核心是构造一个「覆盖索引 + 非空约束」组合，让优化器认为：只扫索引就能完成统计，无需碰数据页。
- 确保目标列定义为
NOT NULL，比如status TINYINT NOT NULL - 在该列上建单列索引：
CREATE INDEX idx_status ON t (status) - 查询时带上等值条件：
SELECT COUNT(*) FROM t WHERE status = 1 - 用
EXPLAIN验证：type应为ref或range，key显示用了idx_status，Extra出现Using index（表示覆盖） - 避免
OR、函数包裹、隐式类型转换，这些会让索引失效
COUNT(二级索引列) 和 COUNT(*) WHERE 条件的区别
两者看似结果一样，但执行逻辑和稳定性差异很大：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
COUNT(status)：不管有没有WHERE，都必须读出每行status值判断是否为 NULL，即使status是NOT NULL，优化器也不自动跳过取值——所以它仍可能回表或扫描更多数据 -
COUNT(*) WHERE status = 1：优化器可直接在idx_status上定位到所有status=1的索引项，每个项只含主键 ID，无需读数据行，Using index成立 - 实测中，后者比前者快 20%~40%，尤其当表宽（行大小）大、主键小（如
INT）时优势更明显 - 注意：如果
status区分度极低（比如 95% 都是 1），索引选择性差，优化器可能仍选全表扫描——此时需考虑前缀索引或业务拆分
容易被忽略的边界问题
你以为加了索引就稳了？这几个点常导致优化失败：
- 事务隔离级别影响可见性判断：即使走了二级索引，InnoDB 仍需对每条索引记录对应的主键做可见性检查，所以高并发长事务下，
COUNT(*) WHERE ...依然可能变慢 - 索引统计信息陈旧：
ANALYZE TABLE t没跑过，优化器误判索引选择性，可能弃用二级索引 - 联合索引顺序陷阱：若建的是
KEY idx_status_type (status, type)，但查询只用status = 1，它能用上；但若查type = 'A'，这个索引就完全无效 -
SHOW TABLE STATUS LIKE 't'返回的Rows是采样估算值，误差可达 40%，不能用于精确分页或强一致性场景
真正压测时，别只看单条 COUNT 耗时——重点观察并发下 buffer pool 命中率和 Innodb_buffer_pool_reads 是否飙升，那才是二级索引没兜住的真实信号。
