100% 展示 MySQL 语句执行的神器-Optimizer Trace

在上一篇文章《用Explain 命令分析 MySQL 的 SQL 执行》中，我们讲解了 Explain 命令的详细使用。但是它只能展示 SQL 语句的执行计划，无法展示为什么一些其他的执行计划未被选择，比如说明明有索引，但是为什么查询时未使用索引等。为此，MySQL 提供了 Optimizer Trace 功能，让我们能更加详细的了解 SQL 语句执行的所有分析，优化和选择过程。

如果您想更深入地了解为什么选择某个查询计划，那么优化器跟踪非常有用。虽然 EXPLAIN 显示选定的计划，但Optimizer Trace 能显示为什么选择计划：您将能够看到替代计划，估计成本以及做出的决策。本篇文章会详细讲解 Optimizer Trace 展示的所有相关信息，并且会辅之一些具体使用案例。

基于成本的执行计划

在了解 Optimizer Trace 的之前，我们先来学习一下 MySQL 是如何选择众多执行计划的。

MySQL 会使用一个基于成本(cost)的优化器对执行计划进行选择。每个执行计划的成本大致反应了该计划查询所需要的资源，主要因素是计算查询时将要访问的行数。优化器主要根据从存储引擎获取数据的统计数据和数据字典中元数据信息来做出判断。它会决定是使用全表扫描或者使用某一个索引进行扫描，也会决定表 join的顺序。优化器的作用如下图所示。

image

优化器会为每个操作标上成本，这些成本的基准单位或最小值是从磁盘读取随机数据页的成本，其他操作的成本都是它的倍数。所以优化器可以根据每个执行计划的所有操作为其计算出总的成本，然后从众多执行计划中，选取成本最小的来最终执行。

既然是基于统计数据来进行标记成本，就总会有样本无法正确反映整体的情况，这也是 MySQL 优化器有时做出错误优化的重要原因之一。

Optimizer Trace 的基本使用

首先，我们来看一下具体如何使用 Optimizer Trace。默认情况下，该功能是关闭的，大家可以使用如下方式打开该功能，然后执行自己需要分析的 SQL 语句，然后再从 INFORMATION_SCHEMA 的 OPTIMIZER_TRACE中查找到该 SQL 语句执行优化的相关信息。

# 1. 打开optimizer trace功能 (默认情况下它是关闭的):
SET optimizer_trace="enabled=on";
SELECT ...; # 这里输入你自己的查询语句
SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
# 当你停止查看语句的优化过程时，把optimizer trace功能关闭
SET optimizer_trace="enabled=off";

这个 OPTIMIZER_TRACE 表有4个列，如下所示：

QUERY：表示我们的查询语句。
TRACE：表示优化过程的JSON格式文本。
MISSING_BYTES_BEYOND_MAX_MEM_SIZE：由于优化过程可能会输出很多，如果超过某个限制时，多余的文本将不会被显示，这个字段展示了被忽略的文本字节数。
INSUFFICIENT_PRIVILEGES：表示是否没有权限查看优化过程，默认值是0，只有某些特殊情况下才会是1，我们暂时不关心这个字段的值。

其中，信息最多也最为重要的就是第二列 TRACE，它也是我们后续分析的重点。