MySQL查询优化器是数据库内核里负责把SQL语句变成可执行方案的核心模块。它并不会直接按照你写的SQL顺序去跑，而是先解析成语法树，再做等价变换和代价估算，最后选出一个它认为成本最低的执行计划。了解这套机制，能帮我们解释很多明明建了索引却没用上的现象。
优化器的两个主要阶段
MySQL优化器的工作大致分为逻辑优化和物理优化。逻辑优化关注SQL语义的等价重写，物理优化关注具体用哪些算法和索引。
逻辑优化
- 视图合并：把简单视图展开到外层查询中
- 子查询转换：将IN子查询转为半连接（semi join）
- 条件化简：去掉恒真或恒假条件，合并WHERE子句
物理优化
物理优化阶段会基于统计信息估算每种执行方式的成本，主要涉及索引选择和连接顺序。
成本模型与统计信息
优化器依赖表统计信息来估算扫描行数，默认使用innodb_index_stats和innodb_table_stats中的数据。总成本约等于IO成本加CPU成本。
| 成本类型 | 说明 |
|---|---|
| IO成本 | 从磁盘或缓冲池读取页面的开销 |
| CPU成本 | 对记录进行比较、过滤的计算开销 |
查看优化器决策过程
我们可以通过EXPLAIN看到优化器最终选的执行计划。下面这段SQL演示了如何观察索引使用情况：
EXPLAIN SELECT user_id, nick_name FROM user_info WHERE age > 18 AND city = 'beijing' ORDER BY create_time DESC LIMIT 10;
如果type列显示ALL，说明做了全表扫描；如果key列有值，说明优化器选了对应索引。
为什么索引有时不被使用
常见原因包括：统计信息过期导致行数估算偏差、对索引列使用函数使索引失效、或者优化器认为回表成本高于全表扫描。
当数据量较小时，优化器可能主动放弃索引，因为随机IO比顺序扫描更慢。
简单示例：连接顺序的挑选
下面用Python伪代码说明优化器如何比较两种连接顺序的成本：
def estimate_cost(order):
# order为表连接顺序列表
rows = 1
cost = 0
for table in order:
rows = rows * table.est_rows
cost += rows * table.io_per_row
return cost
plan_a = estimate_cost([table_a, table_b])
plan_b = estimate_cost([table_b, table_a])
best = plan_a if plan_a < plan_b else plan_b
真实优化器会枚举更多顺序并用剪枝策略减少计算量，但核心思路就是选成本最小的方案。
总结
MySQL查询优化器通过逻辑改写和基于成本的物理优化来选定执行计划。写SQL时应避免隐式类型转换、减少不必要的子查询，并定期用ANALYZE TABLE更新统计信息，让优化器能做出更准确的判断。