MySQL优化器选索引的核心是“谁最省”而非“有就行”，优先扫描逻辑页数最少的索引；COUNT(*)时倾向轻量辅助索引（如单主键索引），但若其因字段宽、NULL多、低选择性或碎片而变“胖”，则退选聚簇索引。

MySQL优化器选索引的底层逻辑：不是“有就行”，而是“谁最省”

MySQL对大表执行COUNT(*)时，**确实会优先考虑辅助索引（二级索引）**，但前提是这个索引“足够小”。它的选择依据不是“有没有索引”，而是扫描该索引所需的逻辑页数是否显著少于扫描聚簇索引（主键索引）。如果辅助索引本身字段宽、重复值多、或者被大量删除导致页碎片严重，它可能比主键索引还“胖”，优化器就会放弃它，退回到扫描主键索引。这在EXPLAIN里表现为type: index但key显示的是PRIMARY。

辅助索引失效的典型场景：字段宽、NULL多、无覆盖

以下情况会让辅助索引在COUNT(*)中失去优势：

• 索引列本身是VARCHAR(255)或TEXT前缀索引，叶子节点体积大，页内能存的记录少，总页数反而上升
• 索引列允许NULL且实际NULL值很多，InnoDB仍需为每条NULL记录维护索引项，空间没节省多少
• 你建的是INDEX idx_status (status)，但表里status只有3个取值，索引高度低但单页数据密度极差，扫描成本不降反升
• 没有COUNT(*)专用的“空索引”——比如只含主键的冗余索引INDEX idx_dummy (id)，这种窄索引才真正轻量

为什么WHERE条件一加，辅助索引就可能白搭？

带WHERE的COUNT(*)（如COUNT(*) WHERE status = 1）能否走索引，关键看过滤条件是否能命中索引的最左前缀。常见失效点：

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

• 查询写成WHERE status IN (1,2)，但索引是单列status——通常还能用，但若范围过大，优化器可能认为全表扫描更便宜
• 索引是(status, create_time)，但查询只用WHERE create_time > '2024-01-01'——直接跳过status，复合索引失效
• status字段类型是TINYINT，但查询条件传了字符串'1'——触发隐式转换，索引无法使用
• 条件用了函数，比如WHERE DATE(create_time) = '2024-01-01'——索引列被包装，无法走索引

验证和干预手段：别猜，用EXPLAIN + handler_read

光看EXPLAIN不够，要确认是否真走了辅助索引，得结合运行时指标：

• 执行EXPLAIN FORMAT=TRADITIONAL SELECT COUNT(*) FROM t，重点看key列是否是你期望的辅助索引名
• 开启HANDLER统计：FLUSH STATUS;后执行COUNT，再查SHOW STATUS LIKE 'Handler_read%';，对比Handler_read_next（遍历索引）和Handler_read_rnd_next（随机回表）的增量——前者高说明确实在扫索引
• 强制指定索引（仅调试用）：SELECT COUNT(*) FROM t USE INDEX (idx_status)，观察执行时间是否下降；若没变化，说明该索引确实不优
• 真正有效的“COUNT专用索引”往往长这样：CREATE INDEX idx_count ON t (id) COMMENT 'lightweight index for COUNT(*)';——只含主键，最窄，无业务负担

复杂点在于：辅助索引是否被采用，取决于当前表的数据分布、缓冲池热度、甚至临时内存配置，同一SQL在不同时间点的执行计划都可能漂移。不能只建一个索引就认为万事大吉，得持续用EXPLAIN和真实耗时交叉验证。