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

在上一篇文章《用Explain 命令分析 MySQL 的 SQL 执行》中，咱们讲解了 Explain 命令的详细使用。可是它只能展现 SQL 语句的执行计划，没法展现为何一些其余的执行计划未被选择，好比说明明有索引，可是为何查询时未使用索引等。为此，MySQL 提供了 Optimizer Trace 功能，让咱们能更加详细的了解 SQL 语句执行的全部分析，优化和选择过程。

若是您想更深刻地了解为何选择某个查询计划，那么优化器跟踪很是有用。虽然 EXPLAIN 显示选定的计划，但Optimizer Trace 能显示为何选择计划：您将可以看到替代计划，估计成本以及作出的决策。本篇文章会详细讲解 Optimizer Trace 展现的全部相关信息，而且会辅之一些具体使用案例。

基于成本的执行计划

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

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

优化器会为每一个操做标上成本，这些成本的基准单位或最小值是从磁盘读取随机数据页的成本，其余操做的成本都是它的倍数。因此优化器能够根据每一个执行计划的全部操做为其计算出总的成本，而后从众多执行计划中，选取成本最小的来最终执行。

既然是基于统计数据来进行标记成本，就总会有样本没法正确反映总体的状况，这也是 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，它也是咱们后续分析的重点。

TRACE 列的基本格式

TRACE 列的内容是一个超级大的 JSON 数据，直接展开而后一条一条解析估计能看到大伙脑袋疼。

因此，咱们先来看一下这坨大 JSON 的骨架。它有三大块内容，也表明着 SQL 语句处理的三个阶段，分别为准备阶段，优化阶段和执行阶段。

接下来，咱们详细介绍一个案例，在案例中介绍涉及到的具体字段和含义。

为何查询未走索引而是全表扫描

首先，SQL 语句查询不使用索引的状况有不少，咱们这里只讨论由于基于成本的优化器认为全表查询执行计划的成本低于走索引执行计划的状况。

以下图这个场景，明明 val 列上有索引，而且 val 现存值也有必定差别性，为何没有使用索引进行查询呢？

咱们按照上文使用 Optimizer Trace 找到其 join_optimization 中 range_analysis 相关数据，它会展现 where 从句范围查询过程当中索引的选择状况

由上图能够看出，MySQL 对比了全表扫描和使用 val 做为索引两个方案的成本，最后发现虽然全表扫描须要扫描更多的行，可是成本更低。因此选择了全表扫描的执行方案。

这是为何呢？明明使用 val 索引能够少扫描 4 行。这其实涉及 InnoDB 中使用索引查询数据行的原理。

Innodb引擎查询记录时在没法使用索引覆盖(也就是须要查询的数据多与索引值，好比该例子中，我要查name，而索引列是 val)的场景下，须要作回表操做获取记录的所需字段，也就是说，经过索引查出主键，再去查数据行，取出对应的列，这样势必是会多花费成本的。

因此在回表数据量比较大时，常常会出现 Mysql 对回表操做查询代价预估代价过大而致使不使用索引的状况。

通常来讲，当SQL 语句查询超过表中超过大概五分之一的记录且不能使用覆盖索引时，会出现索引的回表代价太大而选择全表扫描的现象。且这个比例随着单行记录的字节大小的增长而略微增大。

经过 range_analysis 中的相关数据也能够对 where 从句使用多个索引列，如何选择执行时使用的索引的状况进行分析。

小节

终于，介绍了有关于 MySQL 语句执行分析的 explain 和 Optimizer Trace，下一篇，咱们将分析具体的死锁场景。

我的博客，欢迎来玩