优化器是执行计划的“决策大脑”，不是加速器
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持续验证——而不是期待它自动猜中你脑子里的意图。
