type
status
date
slug
summary
tags
category
icon
password
catalog
sort
在当今数字化时代，数据库如同支撑业务运转的 “心脏”，而 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 许可协议，转载请注明出处。