MySQL优化器选二级索引的核心原因是I/O成本更低：其B+树更“矮胖”，叶子节点仅存索引列值和主键值，不存整行数据，页数远少于聚簇索引，显著减少磁盘读取次数与缓冲区压力。
MySQL优化器选二级索引的核心原因是I/O成本更低
因为二级索引的B+树更“矮胖”：叶子节点只存索引列值 + 主键值，不存整行数据；而聚簇索引（主键索引）叶子节点存的是完整行记录。当表字段多、单行体积大时，同样数量的记录，二级索引占用的页数可能只有聚簇索引的1/5甚至更少。优化器基于cost模型估算，扫1000个二级索引页比扫1000个聚簇索引页快得多——本质是磁盘读取次数更少、缓冲区压力更小。
哪些COUNT写法会触发二级索引选择
COUNT(*)和COUNT(1)几乎总是走最短二级索引（只要存在），因为它们无需读取任何字段值，只需统计索引记录条数；COUNT(主键字段)也会走二级索引，但Server层仍要取主键值判断是否为NULL（尽管主键不可能为NULL，逻辑上仍执行）；COUNT(字段)能否走二级索引取决于该字段是否有索引且是否能覆盖判NULL需求——比如COUNT(name)若name上有idx_name，就会走它，但每条记录都得取出name值做NULL检查。
EXPLAIN显示key为NULL不代表没走索引
在MySQL 8.0+中，即使你建了二级索引，EXPLAIN SELECT COUNT(*) FROM t也可能显示key: NULL。这不是bug，而是优化器内部跳过了传统索引选择路径，直接调用轻量级索引遍历接口。此时不能只看key列，必须结合：
-
Extra: Using index—— 关键信号，说明用了覆盖索引、没回表 - 状态变量
Handler_read_next增幅显著（比如从0飙升到百万级）—— 表明实际在遍历索引记录 -
SHOW STATUS LIKE 'Handler%'前后对比，比Handler_read_rnd或Handler_read_first更可靠
加WHERE条件后二级索引可能被弃用
二级索引的“快”只在无过滤或简单等值条件下成立。一旦出现以下情况，优化器大概率放弃二级索引，转而走聚簇索引甚至临时文件：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
WHERE条件无法命中同一二级索引（比如你在status上建了索引，但查询写的是WHERE created_at > '2025-01-01'） - 条件涉及函数或表达式（如
WHERE YEAR(created_at) = 2025） - 范围查询跨度太大，优化器预估回表代价过高，宁可全扫聚簇索引
这时候EXPLAIN里key可能变回PRIMARY，Extra出现Using where但没了Using index。
真正容易被忽略的是：二级索引对COUNT的加速效果，高度依赖“无额外字段读取”这个前提。一旦你要判NULL、要回表、要排序、要JOIN，那个“最短索引”的优势就瞬间瓦解。
