对于 MySQL 5.6 以及之前的版本来说，查询优化器就像是一个黑盒子一样，我们只能通过
EXPLAIN
语句查看到最后优化器决定使用的执行计划，却无法知道它为什么做这个决策。这对于一部分想知道为什么择选执行计划，而不选择其他执行计划的朋友来说简直是灾难：“我就觉得使用其他的执行方案⽐
EXPLAIN
输出的这种方案强，凭什么优化器做的决定和我想的不一样呢？”
从
MySQL 5.6之后，提供
optimizer trace功能，因此我们主要介绍使用
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
的值是控制输出格式的，可以是json，可以是文本，如果为
on
那么所有输出都将在一行中展示，不适合⼈阅读，所以我们就保持其默认值为
off或者配置为json格式。开启trace功能：
set session optimizer_trace="enabled=on",end_markers_in_json=on;
查看执行计划信息：
开启trace功能后，我们就可以查看优化过程的查询语句，当该查询语句执行完成后，就可以到
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 session optimizer_trace="enabled=on",end_markers_in_json=on;
Query OK, 0 rows affected (0.01 sec)
步骤二： 输入查询语句。
mysql> select * from test;
步骤三： 从
optimizer_trace 表中查看上一个查询的优化过程。
mysql> select * from information_schema.OPTIMIZER_TRACE;
--可以把内容输出到一个文件中查询
mysql> SELECT TRACE INTO DUMPFILE "E:\\test.trace" FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
步骤四： 停⽌查看语句的优化过程时，把 optimizer trace 功能关闭。
mysql> set session optimizer_trace="enabled=off";
Query OK, 0 rows affected (0.01 sec)
优化过程大致分为了三个阶段：
prepare 阶段
optimize 阶段
execute 阶段
我们所说的基于成本的优化主要集中在
optimize 阶段，我们主要关注
optimize 阶段的
"rows_estimation" 这个过程。这个过程深入分析了对查询的各种执行方案的成本，对于多表连接查询来说，我们更多需要关注
"considered_execution_plans" 这个过程，这个过程里会写明各种不同的连接方式所对应的成本。反正优化器最终会选择成本最低的那种方案来作为最终的执行计划，也就是我们使用
EXPLAIN 语句所展现出的那种方案。
