mysql如何选择执行计划_mysql优化器决策流程

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，也能避免多数“明明有索引却不走”的问题。