MySQL优化器决定“怎么走”，即从所有访问路径中选择成本最低的执行计划，负责索引选择、JOIN顺序和排序优化；它基于统计信息建模，但受数据分布倾斜、统计过期、隐式类型转换等影响，导致EXPLAIN结果与预期不符。
优化器决定“怎么走”，而不是“走不走”
MySQL 优化器的核心作用，是在解析完 SQL 后、执行前，从所有可能的访问路径中，选出它认为 cost（成本）最低的一条执行计划。它不判断语句是否合法、也不负责返回结果——那是解析器和执行器的事；它只回答一个问题：“这张表该用哪个索引？多表 JOIN 时谁先查、谁后查？ORDER BY 能否利用索引避免排序？”
为什么 EXPLAIN 看到的计划，有时和你预想的不一样
优化器不是靠经验或规则硬匹配，而是基于统计信息（如 INFORMATION_SCHEMA.STATISTICS、ANALYZE TABLE 产生的行数/基数估算）做成本建模。常见偏差原因包括：
-
rows字段是估算值，不是真实扫描行数；如果表数据分布倾斜（比如 status=‘pending’ 占 95%，而你查的是 ‘done’），优化器可能误判索引有效性 - 统计信息过期：大表批量导入/删除后未运行
ANALYZE TABLE，会导致优化器“以为”某索引选择性高，实际全扫 - 隐式类型转换让索引失效，但
EXPLAIN仍显示key有值（例如WHERE user_id = '123'对INT字段，触发字符串转数字，索引无法下推）
type=ALL 是警报，但不是唯一指标
全表扫描（type=ALL）确实危险，但它未必代表慢——小表（
-
rows值远大于实际匹配行数（比如估算 50000，实际只返回 3 行） -
Extra出现Using filesort或Using temporary，尤其在WHERE+ORDER BY+LIMIT组合中，说明排序/分组被迫在服务层完成 -
key为空但possible_keys有值，说明优化器主动弃用了可用索引（通常因WHERE条件未覆盖索引最左前缀，或OR导致索引失效）
别只信 EXPLAIN，要结合 optimizer_trace 看决策过程
EXPLAIN 告诉你“选了哪条路”，但不告诉你“为什么没选另一条”。开启优化器跟踪后：
SET optimizer_trace="enabled=on"; SELECT * FROM your_table WHERE ...; SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
你能看到优化器如何评估各个索引的成本、是否考虑了索引合并、为何放弃使用某个索引——比如发现它计算出走 idx_a_b 的 cost 是 1200，而走 idx_a_c 是 850，于是选了后者，哪怕你直觉认为 b 字段更关键。
这种细粒度反馈，才是调优时真正需要的依据，而不是凭感觉加索引或重写 SQL。
