MySQL优化器选错索引本质是统计信息失真导致成本估算错误；常见原因包括ANALYZE TABLE长期未执行、字段值分布倾斜、虚拟/生成列支持弱、分区表统计未持久化，且成本模型未考虑SSD性能、buffer pool命中率及并发锁开销。
MySQL优化器选错索引，本质是“估算错了”
它不是故意选高 cost 的方案，而是基于过期/失真的统计信息，算出来那个“看似便宜”的索引，实际执行时更慢。你看到的 EXPLAIN 中 rows 偏差大、type 退化为 ALL 或 index，基本就是这个原因。
哪些情况会让 cost 估算严重失真
优化器依赖表级和索引级的统计信息做成本预估，以下几类问题会直接污染估算基础：
-
ANALYZE TABLE长期没跑过，尤其是数据批量导入或大范围DELETE后，rows字段可能还是半年前的值 - 字段值分布极度倾斜，比如
status字段 95% 是'pending'，但优化器仍按均匀分布估算选择性 - 使用了虚拟列、生成列或 JSON 字段上的索引，InnoDB 的统计信息采集机制对这类结构支持弱
- 分区表未启用
innodb_stats_persistent，每个分区的统计信息独立且易过期
为什么 optimizer_trace 显示 cost 更低，但实际更慢
因为 cost 模型只算“理论开销”，不反映真实硬件瓶颈：
- IO 成本按“随机读一页 = 1”计，但 SSD 上顺序读和随机读差距已大幅缩小，模型没更新
- CPU 成本固定设为每行 0.1，但实际比较开销取决于字段类型（比如
varchar(2000)比tinyint耗更多 CPU） - 完全忽略 buffer pool 命中率：一个被缓存住的全表扫描，可能比反复刷盘的索引回表快得多
- 没计入锁竞争、MVCC 版本链遍历开销，这些在高并发 UPDATE 场景下可能占主导
真正该盯住的不是 cost 数字，而是这三处
别被 cost=1234 迷惑，现场排查优先看：
-
EXPLAIN的rows是否远大于实际返回行数——说明过滤性判断失效 -
Extra里有没有Using filesort或Using temporary——这是成本爆炸的明确信号 -
key和key_len是否符合预期——比如你建了INDEX(a, b)，但key_len只显示 a 的长度，说明 b 没参与索引查找
统计信息不准、模型假设脱离现实、执行时环境变量缺失——这三个层面叠加，才是 cost 数字“看着合理实则误人”的根源。
