优化器是执行计划的“决策大脑”，负责从所有路径中选择预估成本最低的方案；其成本基于I/O、CPU等加权值，非实际耗时，EXPLAIN输出即最终决定而非建议。

优化器是执行计划的“决策大脑”，不是加速器

MySQL优化器不负责执行SQL，也不直接提升速度；它的唯一任务是：在所有可能的执行路径中，选一个预估成本最低的方案。这个“成本”不是时间，而是MySQL内部估算的I/O次数、CPU开销等加权值。你看到的EXPLAIN输出，就是它拍板后的结果——不是建议，是已决定的路线图。

为什么EXPLAIN显示用了索引，但查询还是慢？

因为优化器只看统计信息做估算，而这些信息可能过期或失真。比如：ANALYZE TABLE没跑过、表数据突增10倍、索引字段存在大量NULL或重复值，都会导致优化器误判“走索引比全表扫描便宜”。常见表现：

• type为ref但rows高达几十万——说明它以为能快速定位，实际要扫大量索引项
• key列有值，但Extra里出现Using where; Using index甚至Using filesort——覆盖索引没建对，仍需回表或排序
• 明明有复合索引，却只用上最左前缀的一部分，其余条件被下推到Server层过滤

优化器不选你期望的索引？先检查这三个硬性条件

优化器跳过某个索引，往往不是bug，而是它被规则排除了。必须同时满足：

• 索引列参与了WHERE、ON或ORDER BY等可下推的条件（不能是函数包裹，如WHERE YEAR(create_time) = 2025）
• 索引字段的数据类型与查询值严格匹配（INT列传字符串'123'会触发隐式转换，索引失效）
• 该索引的统计信息未被标记为“不可信”（可通过SHOW INDEX FROM table_name查看Cardinality是否明显偏低）

想干预优化器选路？FORCE INDEX比HINT更可控

MySQL 8.0+虽支持/*+ USE_INDEX(...) */这类Optimizer Hint，但生产环境更推荐显式控制：

SELECT u.name, o.amount 
FROM users u FORCE INDEX (idx_status_created) 
JOIN orders o ON u.id = o.user_id 
WHERE u.status = 'active' AND u.created_at > '2025-01-01';

注意：FORCE INDEX会强制使用指定索引（即使优化器认为更贵），但不会阻止优化器调整连接顺序；若要锁死连接顺序，得配合STRAIGHT_JOIN。滥用会导致统计信息更新后行为突变，务必在EXPLAIN验证后再上线。

优化器从不保证“最优”，只保证“基于当前信息最不差”。真正稳定的性能，靠的是让统计信息准、索引设计贴合查询模式、以及用EXPLAIN持续验证——而不是期待它自动猜中你脑子里的意图。