MySQL优化器基于成本模型估算I/O与CPU开销选择索引，而非实际速度；其决策严重依赖统计信息，过期或不准会导致误判，需定期ANALYZE TABLE并合理设计索引与直方图。
MySQL优化器怎么决定用哪个索引
优化器不是“选最快”的索引，而是基于成本模型估算不同执行路径的 I/O + CPU 开销，选预估成本最低的那个。这个估算严重依赖统计信息（如 INFORMATION_SCHEMA.STATISTICS 和 ANALYZE TABLE 生成的数据分布），一旦统计过期或不准确，就会选错。
常见误判场景包括：
- 表刚导入大量数据但没
ANALYZE TABLE，优化器仍按空表或旧分布估算 - 字段有严重数据倾斜（比如
status字段 95% 是'active'），直方图未启用时无法反映真实选择率 - 复合索引顺序和
WHERE条件顺序不匹配，导致部分索引字段无法用于 range 访问
FORCE INDEX 有用但治标不治本
当发现优化器选了全表扫描而你确信某个索引更优，可以用 FORCE INDEX 强制走索引，例如：
SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 AND status = 'paid';
但这只是绕过优化器决策，不解决根本问题。后续如果数据分布变化、索引结构调整，或 MySQL 升级导致成本模型变更，FORCE INDEX 可能反而让查询变慢。更稳妥的做法是：
- 确认
user_id和status在索引中的顺序是否匹配查询条件（最左前缀原则） - 检查该索引的
cardinality是否合理（对比SHOW INDEX FROM orders输出） - 必要时添加直方图：
ANALYZE TABLE orders UPDATE HISTOGRAM ON user_id, status;
EXPLAIN 的 key_len 和 rows 哪个更关键
key_len 表示实际用到的索引字节数，能帮你判断是否触发了最左前缀匹配；rows 是优化器预估扫描行数，直接关联成本估算。但要注意：
-
rows值不准很常见——它基于采样统计，不是真实值；若显示rows=1但实际扫百万行，大概率是统计信息陈旧 -
key_len为 0 或远小于索引定义长度，说明索引未被有效利用（比如用了函数、类型隐式转换、或条件含OR破坏索引连续性） - 真正要盯的是
type字段：出现ALL（全表扫描）或index（全索引扫描）时，即使rows很小也得警惕
optimizer_switch 里哪些开关影响最大
默认开启的 index_merge、range_optimizer_max_mem_size、use_index_extensions 都可能改变执行计划。最常需要干预的是：
-
index_merge=on：允许合并多个单列索引，但有时会比一个复合索引更慢；若观察到执行计划突然从ref变成index_merge且性能下降，可临时关掉测试 -
condition_fanout_filter=off：关闭条件下推的扇出估算优化，在某些 JOIN 场景下反而让计划更稳定（MySQL 8.0.22+ 默认开启，但复杂 WHERE + 子查询时易误估） - 修改方式：
SET SESSION optimizer_switch='index_merge=off';，仅对当前连接生效，上线前务必在测试环境验证
优化器决策不是黑盒，但也不是靠调参就能一劳永逸的事。数据分布、索引设计、统计质量三者缺一不可，其中最容易被忽略的是定期更新统计信息——哪怕只是每天凌晨跑一次 ANALYZE TABLE，也能避免多数“明明有索引却不走”的问题。
