在当今数字化时代，数据库如同支撑业务运转的 “心脏”，而 MySQL 作为全球最流行的开源数据库之一，更是承载着无数应用的核心数据流转。当我们谈论 MySQL 性能时，有一个组件始终站在幕后却至关重要 —— 那就是优化器。它像一位 “隐形指挥官”，每一条 SQL 语句的执行路径、每一次索引选择、每一组表连接顺序，都由它精密决策。一个好的优化器能让复杂查询 “行云流水”，而一次决策失误则可能让系统陷入 “停滞泥潭”。
回顾 MySQL 二十余年的发展历程，优化器的进化堪称一部 “性能突围史”。从 2001 年依赖固定规则的 “愣头青”，到学会用成本模型算账的 “小学生”；从能处理复杂子查询的 “初中生”，再到如今支持动态调整的 “成熟决策者”，它的每一次升级都在回应着业务场景的深刻变革。当数据量从十万级跃升至亿级，当查询从单表筛选变为多表关联分析，当硬件从机械硬盘迭代到云服务器，优化器始终在 “适配需求” 与 “突破瓶颈” 的循环中持续进化。
对于开发者和 DBA 而言，理解优化器不仅是解决慢查询的 “必修课”，更是掌控数据库性能的 “关键钥匙”。你是否遇到过 “明明建了索引却不走” 的困惑？是否因升级版本后查询性能骤降而手足无措？是否想知道复杂查询背后的执行逻辑？这些问题的答案，都藏在优化器的进化轨迹里。
本栏目将以 “进化史” 为脉络，带你深入 MySQL 优化器的世界。我们会从早期的规则驱动时代讲起，细数 CBO 革命、超图优化等关键突破，解析每一代优化器的核心特性与实战价值；也会分享版本升级中的避坑指南、参数调优的实战技巧，让你既能看懂优化器的 “决策逻辑”，也能在实际工作中精准调控性能。
读懂优化器的进化，便是读懂 MySQL 性能的底层逻辑。接下来，让我们从优化器的 “童年时代” 开始，揭开这部 “性能进化史” 的序幕。
第一章 早期探索：规则驱动的初级阶段（2001-2005）
1.1 时代背景：简单场景下的“够用就好”
2000年代初，MySQL刚在开源数据库领域崭露头角。那时候互联网还处于萌芽期，主流应用多是简单的Web网站和小型业务系统，数据量普遍不大——多数表的行数不超过10万，查询也以单表简单查询为主。当时用户对数据库的核心需求是“能跑起来”，对性能的要求不高，这让简单直接的优化器设计成为可能。
1.2 核心特征：RBO主导的“机械执行”
这个阶段的优化器（以MySQL 3.23到5.0早期版本为代表）完全依赖“基于规则的优化器（RBO）”。它的逻辑简单到近乎机械：按预设的固定规则选择执行计划，完全不考虑实际数据分布。
最典型的表现是索引选择的“教条主义”。比如查询中只要出现
WHERE age > 18，优化器就会固执地选择age索引，哪怕全表90%的数据都满足这个条件（此时全表扫描反而更快）。这就像个只会按说明书操作的新手，不懂灵活变通。多表连接处理更是“认死理”。当时的优化器严格按照
FROM子句中的表顺序执行连接，比如FROM a JOIN b JOIN c就一定先扫a、再关联b、最后连接c。这在数据量增大后成了大问题——如果开发时把大表放在前面，优化器会硬生生用大表做驱动表，导致连接效率极低。我早年在电商公司遇到过一个案例：300万行的用户表和500万行的订单表关联，因大表在前，查询跑了20多分钟都没结果，根源就是优化器不会调整连接顺序。1.3 技术局限：没有“成本”概念的短板
这一时期的优化器源码简单得惊人。核心函数
JOIN::optimize()中，索引选择逻辑只有寥寥几行，判断索引好坏只看是否为主键或唯一索引，完全没有“成本估算”的概念。就像买菜只看菜名不看价格，更不考虑新鲜度，这种“拍脑袋”的决策在数据量增长后逐渐力不从心。随着2000年代中期电商、社交应用兴起，单表行数突破百万、多表关联需求增多，RBO的局限性开始凸显，优化器升级迫在眉睫。第二章 成本觉醒：CBO带来的第一次革命（2005-2013）
2.1 时代背景：数据量激增倒逼优化升级
2005年后，互联网进入快速发展期。电商平台的订单表、社交网站的用户关系表数据量急剧膨胀，千万级行数的表越来越常见，多表关联查询成了常态。此时RBO“一刀切”的规则已无法应对复杂场景——同样的查询在不同数据分布下性能差异极大，用户对“智能选计划”的需求越来越迫切。
2.2 核心突破：CBO让优化器学会“算账”
2005年发布的MySQL 5.0版本，首次引入“基于成本的优化器（CBO）”，这是优化器发展的里程碑。CBO的核心逻辑是：根据表的统计信息（行数、索引基数、数据分布等）估算不同执行计划的成本，选择成本最低的方案。
这个“成本”最初是简单的“行数×固定系数”计算，虽然粗糙，但相比RBO已是巨大进步。比如判断是否走索引时，CBO会估算索引扫描的IO成本和全表扫描的IO成本，哪个低就选哪个，不再盲目依赖规则。
2.3 关键升级：5.6版本的实用功能补位
2013年的MySQL 5.6版本进一步强化了CBO能力，针对性解决了当时的性能痛点：
- Condition Filtering（条件过滤）：解决了“WHERE条件过滤效果估算不准”的问题。优化器能根据统计信息预测条件过滤后的行数，避免因估算偏差选错执行计划。当时有个短视频平台的用户表，因启用该功能，带多条件的查询性能提升3倍——终于能精准识别哪些条件能过滤掉大部分数据了。
- MRR与BKA优化：针对机械硬盘时代的“随机IO瓶颈”。MRR能把零散的索引查询转化为顺序访问，减少磁盘寻道；BKA则通过批量处理连接键值，降低多表连接的IO次数。有个游戏日志表的案例：启用这两个功能后，关联查询从8秒降到1.2秒，核心就是把随机IO变成了高效的顺序IO。
2.4 仍存短板：统计信息滞后的烦恼
不过这一阶段的CBO还不够成熟。统计信息需要手动更新（
ANALYZE TABLE），一旦数据分布变化（比如大量插入新数据），估算就会严重偏差。我曾遇到过优化器预估扫描1000行、实际却扫了10万行的情况，就是因为统计信息太久没更新。这也让DBA多了个日常工作：定期维护统计信息，避免优化器“拍错板”。第三章 能力跃升：复杂场景的攻坚阶段（2013-2018）
3.1 时代背景：移动互联网催生复杂查询
2013年后，移动互联网爆发，App用户量和数据量呈指数级增长。电商的商品推荐、社交的信息流、金融的风控分析等场景，催生了大量包含子查询、派生表、多表连接的复杂查询。此时优化器不仅要“算成本”，还要能处理更复杂的SQL结构，提升查询解析效率。
3.2 5.7版本：子查询与条件下推的突破
2015年发布的MySQL 5.7，针对复杂查询痛点做了大幅优化：
- 派生表条件下推：解决了“子查询无效扫描”问题。以前子查询里的条件不会传递到主查询，比如
SELECT * FROM (SELECT * FROM t1) a WHERE a.age > 18会全表扫描t1，再过滤结果。5.7后优化器能把age > 18直接下推到子查询，从源头减少扫描行数。
- 子查询自动转换：通过
convert_IN_to_EXISTS()函数，把低效的WHERE id IN (子查询)自动转为EXISTS形式。有个电商商品分类查询的案例：原IN子查询跑5秒多，转换后仅需0.3秒，开发一度以为是代码被修改过。
- 成本模型可调优：引入
cost_model系统表，支持调整IO和CPU的成本权重。在SSD服务器上调低IO权重后，优化器会更倾向用索引扫描，贴合硬件特性。
3.3 8.0版本：架构重构与超图优化
2018年的MySQL 8.0是优化器的又一次重大升级，核心目标是支撑更复杂的业务场景：
- 超图优化器（Hypergraph Optimizer）：2020年8.0.22版本后成为默认优化器。以前的优化器只能生成“左深树”连接（像串糖葫芦一样逐个连表），超图优化器能生成“丛生树”（同时连接多个表），大幅提升多表连接效率。对10表以上的复杂查询，性能提升常达30%以上。
- 迭代器执行器：取代旧的QEP_TAB结构，支持算子下推和并行执行，让复杂查询响应更稳定，不再忽快忽慢。
- 直方图统计：解决非等值查询（
>,<,BETWEEN）估算不准的问题。金融客户的风控系统用了直方图后，金额范围查询性能提升近10倍，误差率从30%降到5%以内。
第四章 持续精进：适配多元场景的成熟阶段（2018至今）
4.1 时代背景：混合负载与云原生需求
近年来，数据库面临的场景越来越多元：既要支撑高并发的OLTP交易，又要处理复杂的OLAP分析，还得适配云环境的弹性需求。优化器需要在效率、稳定性、适应性之间找到平衡。
4.2 核心优化：针对性解决实际痛点
8.0后续版本持续打磨优化器能力：
- 哈希表性能升级：8.0.30后采用更高效的哈希实现，提升
GROUP BY和DISTINCT的聚合效率。日志分析客户升级后，大表聚合查询平均提速40%。
- 自适应能力增强：支持执行中动态调整计划，比如发现哈希连接比嵌套循环慢时自动切换算法；自适应哈希索引根据访问频率动态调整，减少无效索引开销。
- 社区生态扩展：Percona、MariaDB等分支各有优化，比如MariaDB的
optimizer_use_condition_selectivity参数默认值更激进，部分场景估算更准，但也带来分支兼容性差异，迁移时需格外注意。
4.3 调优核心：关键参数的实战价值
历代优化器参数是性能调优的“钥匙”，每个参数都对应特定问题：
optimizer_trace（5.6+）：打印优化器决策过程，排查慢查询的神器，但线上常开有20%性能损耗，需谨慎使用。
derived_merge（5.7+）：控制派生表合并，关闭可临时解决条件下推导致的优化器bug。
hypergraph_optimizer（8.0.22+）：复杂查询必开，曾有客户因关闭该参数，报表查询从5分钟降到30秒。
第五章 进化逻辑与升级经验
5.1 优化器进化的底层逻辑
二十多年的发展，优化器的进化始终围绕三个核心方向：
- 从“拍脑袋”到“数据驱动”：从固定规则到成本模型，再到实时统计与自适应调整，决策越来越依赖数据。
- 从“单一场景”到“全局协同”：从单表优化到多表连接，再到硬件适配和混合负载，考虑维度持续扩展。
- 从“静态计划”到“动态适应”：从生成后不变的计划，到能根据实时数据调整策略，像导航软件一样灵活。
5.2 版本升级的避坑指南
升级优化器常遇“水土不服”，几个经典案例值得关注：
- 5.6升5.7的子查询问题：5.7对子查询优化太激进，部分
NOT IN被强转NOT EXISTS后变慢，需用optimizer_hints禁用转换。
- 8.0超图优化器内存问题：复杂查询可能消耗大量内存，调小
optimizer_memory参数可限制内存使用。
- 统计信息兼容性：8.0直方图与旧版本不兼容，升级后必须重跑
ANALYZE TABLE，否则性能会波动。
结语
从2001年的“规则愣头青”到如今的“智能决策者”，MySQL优化器的进化史，也是互联网数据规模与业务复杂度增长的缩影。它的每一次升级都在解决当时的核心痛点——从应对简单查询到支撑复杂场景，从依赖人工调优到实现自适应优化。理解这段历程，不仅能掌握调优技巧，更能预判优化器的发展方向，让数据库更好地服务于业务增长。
- 作者:Honesty
- 链接:https://blog.hehouhui.cn/archives/mysql-optimizer-evolution-history-performance-optimization-guide-column-preface
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。