MySQL查询优化器的核心任务是选择代价最低的执行路径，基于统计信息估算I/O与CPU成本，经历逻辑与物理优化阶段，依赖准确统计信息和合理SQL写法。
MySQL 查询优化器的核心任务是为每条 SQL 语句选择“代价最低”的执行路径，而不是“最快”或“最直观”的写法。它不执行 SQL，只做计划生成；实际执行由存储引擎完成。
优化器如何评估执行成本
优化器基于统计信息（如索引基数、表行数、数据分布）估算不同执行方式的 I/O 和 CPU 开销。主要成本项包括：随机读页次数、排序缓冲区使用量、临时表创建开销等。例如，对一个 100 万行的表，优化器会对比“走主键全扫描”和“用二级索引 + 回表”两种方式的预估读页数，选小的那个。
- 统计信息来自 INFORMATION_SCHEMA.STATISTICS 和 ANALYZE TABLE 更新的数据分布直方图（MySQL 8.0+ 支持）
- 成本模型参数可调，比如 optimizer_cost_weight 系列变量影响 I/O 与 CPU 权重
- 不考虑网络传输、客户端解析等外部开销
常见优化阶段与关键决策点
一条 SELECT 语句通常经历：语法解析 → 逻辑优化（重写）→ 物理优化（选访问路径）。其中几个关键环节直接影响最终执行计划：
- 谓词下推：把 WHERE 条件尽可能提前到 JOIN 或扫描阶段，减少中间结果集。例如 SELECT * FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'done' 中，优化器会尝试将 status 过滤下推到 t2 的访问层
- JOIN 顺序重排：对多表 JOIN，优化器枚举不同关联顺序（如 t1–t2–t3 或 t2–t1–t3），按预估结果集大小升序排列驱动表（小结果集优先作驱动）
- 索引选择：当多个索引可命中时，比较它们的过滤效率（ref_key vs range_key）、覆盖程度（是否避免回表）、有序性（是否支持 ORDER BY 免排序）
为什么 EXPLAIN 显示的计划有时不符合预期
优化器依赖的统计信息可能过期或失真，尤其在数据倾斜严重、大范围 INSERT/DELETE 后未及时 ANALYZE 的场景下。例如某字段值分布极不均匀（95% 是 'A'，其余分散），优化器仍按均匀分布估算，导致本该走索引的查询选了全表扫描。
- 用 SHOW INDEX FROM tbl 查看 cardinality 值，偏低或为 0 表示统计不准
- 强制指定索引可用 FORCE INDEX，但属临时手段；根治需定期 ANALYZE TABLE 或开启 innodb_stats_auto_recalc=ON
- 某些 SQL 结构（如函数包裹索引列、隐式类型转换）会让优化器直接放弃使用索引，即使 EXPLAIN 显示 type=range 也可能实际未生效
开发者能做的关键配合动作
优化器再智能，也无法弥补设计缺陷或模糊表达。写出“利于优化”的 SQL 比调优参数更有效：
- 避免在 WHERE 子句中对索引列使用函数或运算，如 WHERE YEAR(create_time) = 2023 → 改为 WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'
- 多列索引注意最左前缀匹配，INDEX(a,b,c) 可用于 WHERE a=1 AND b>10，但不能用于 WHERE b=10
- 用 EXPLAIN FORMAT=JSON 查看详细成本估算（cost_info 字段），比传统 EXPLAIN 更易定位瓶颈环节
