优化器是执行计划的“决策大脑”，负责从所有路径中选择预估成本最低的方案；其成本基于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) = 2024） - 索引字段的数据类型与查询值严格匹配（
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 > '2024-01-01';
注意：FORCE INDEX会强制使用指定索引（即使优化器认为更贵），但不会阻止优化器调整连接顺序；若要锁死连接顺序，得配合STRAIGHT_JOIN。滥用会导致统计信息更新后行为突变，务必在EXPLAIN验证后再上线。
EXPLAIN持续验证——而不是期待它自动猜中你脑子里的意图。 
