作者：Mutlis
CSDN & 阿里云 & 知乎 等平台优质作者，擅长Oracle & MySQL等主流数据库系统的维护和管理等
本文来源：原创投稿
前言
对于 MySQL 5.6 以及之前的版本来说，查询优化器就像是一个黑盒子一样，你只能通过 EXPLAIN 语句查看到最后优化器决定使用的执行计划，却无法知道它为什么做这个决策。这对于一部分喜欢刨根问底的⼩伙伴来说简直是灾难：“我就觉得使用其他的执行方案⽐ EXPLAIN 输出的这种方案强，凭什么优化器做的决定和我想的不一样呢？”这篇文章主要介绍使用 optimizer trace 查看优化器生成执行计划的整个过程。
optimizer trace 表的神奇功效
在 MySQL 5.6 以及之后的版本中，设计 MySQL 的大叔贴⼼的为这部分小伙伴提出了一个 optimizer trace 的功能，这个功能可以让我们方便的查看优化器生成执行计划的整个过程，这个功能的开启与关闭由系统变量 optimizer_trace 决定，我们看一下：
mysql> show variables like 'optimizer_trace';
+-----------------+--------------------------+
| Variable_name | Value |
+-----------------+--------------------------+
| optimizer_trace | enabled=off,one_line=off |
+-----------------+--------------------------+
1 row in set (0.01 sec)可以看到 enabled 值为 off，表明这个功能默认是关闭的。
小提示：
one_line的值是控制输出格式的，如果为on那么所有输出都将在一行中展示，不适合⼈阅读，所以我们就保持其默认值为off吧。
如果想打开这个功能，必须⾸先把 enabled 的值改为 on，就像这样：
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.00 sec)然后我们就可以输入我们想要查看优化过程的查询语句，当该查询语句执行完成后，就可以到 information_schema 数据库下的 OPTIMIZER_TRACE 表中查看完整的优化过程。这个 OPTIMIZER_TRACE 表有 4 个列，分别是：
-
QUERY：表示我们查询的语句； -
TRACE：表示优化过程的 JSON 格式⽂本； -
MISSING_BYTES_BEYOND_MAX_MEM_SIZE：由于优化过程可能会输出很多，如果超过某个限制时，多余的⽂本将不会被显示，这个字段展示了被忽略的⽂本字节数； -
INSUFFICIENT_PRIVILEGES：表示是否没有权限查看优化过程，默认值是 0，只有某些特殊情况下才会是 1，我们暂时不关心这个字段的值。
完整的使用 optimizer trace 功能的步骤总结如下：
步骤一： 打开 optimizer trace 功能 (默认情况下它是关闭的)。
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.01 sec)
步骤二： 输入查询语句。
SELECT ...;步骤三： 从 optimizer_trace 表中查看上一个查询的优化过程。
SELECT * FROM information_schema.OPTIMIZER_TRACE;步骤四： 可能你还要观察其他语句执行的优化过程，重复上边的第 2、3步。
步骤五： 当你停⽌查看语句的优化过程时，把 optimizer trace 功能关闭。
mysql> SET optimizer_trace="enabled=off";
Query OK, 0 rows affected (0.01 sec)现在我们有一个搜索条件比较多的查询语句，它的执行计划如下：
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key2 可以看到该查询可能使用到的索引有3个，那么为什么优化器最终选择了idx_key1而不选择其他的索引或者直接全表扫描呢？这时候就可以通过otpimzer trace 功能来查看优化器的具体工作过程：
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM s1 WHERE key1 > 'z' AND key2 SELECT * FROM information_schema.OPTIMIZER_TRACEG MySQL 可能会在之后的版本中添加更多的优化过程信息。不过杂乱之中其实还是蛮有规律的，优化过程大致分为了三个阶段：
- prepare 阶段
- optimize 阶段
- execute 阶段
我们所说的基于成本的优化主要集中在 optimize 阶段，对于单表查询来说，我们主要关注 optimize 阶段的 "rows_estimation" 这个过程。这个过程深入分析了对单表查询的各种执行方案的成本，对于多表连接查询来说，我们更多需要关注 "considered_execution_plans" 这个过程，这个过程里会写明各种不同的连接方式所对应的成本。反正优化器最终会选择成本最低的那种方案来作为最终的执行计划，也就是我们使用 EXPLAIN 语句所展现出的那种方案。
最后，我们为感兴趣的小伙伴展示一下通过查询 OPTIMIZER_TRACE 表得到的输出（我使用#后跟随注释的形式为大家解释了优化过程中的一些比较重要的点，建议用电脑屏幕观看）：
*************************** 1. row ***************************
# 分析的查询语句是什么
QUERY: SELECT * FROM s1 WHERE key1 > 'z' AND key2 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z') and (`s1`.`key2` 'z')",
"table_condition_attached": "((`s1`.`common_field` = 'abc') and (`s1`.`key2` 大家看到这个输出的第一感觉就是这文本也太多了点吧，其实这只是优化器执行过程中的一小部分。
如果有小伙伴对使用 EXPLAIN 语句展示出的对某个查询的执行计划很不理解，大家可以尝试使用 optimizer trace 功能来详细了解每一种执行方案对应的成本，相信这个功能能让大家更深入的了解 MySQL 查询优化器。
关于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
SQLE 获取
| 类型 | 地址 |
|---|---|
| 版本库 | https://github.com/actiontech/sqle |
| 文档 | https://actiontech.github.io/sqle-docs-cn/ |
| 发布信息 | https://github.com/actiontech/sqle/releases |
| 数据审核插件开发文档 | https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_audit… |
提交有效 pr，高质量 issue，将获赠面值 200-500 元（具体面额依据质量而定）京东卡以及爱可生开源社区精美周边！更多关于 SQLE 的信息和交流，请加入官方QQ交流群：637150065
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
