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

在上一篇文章《用Explain 命令分析 MySQL 的 SQL 执行》中,我们讲解了 Explain 命令的详细使用 。但是它只能展示 SQL 语句的执行计划,无法展示为什么一些其他的执行计划未被选择,比如说明明有索引,但是为什么查询时未使用索引等 。为此,MySQL 提供了 Optimizer Trace 功能,让我们能更加详细的了解 SQL 语句执行的所有分析,优化和选择过程 。
如果您想更深入地了解为什么选择某个查询计划,那么优化器跟踪非常有用 。虽然 EXPLAIN 显示选定的计划,但Optimizer Trace 能显示为什么选择计划:您将能够看到替代计划,估计成本以及做出的决策 。本篇文章会详细讲解 Optimizer Trace 展示的所有相关信息,并且会辅之一些具体使用案例 。
基于成本的执行计划在了解 Optimizer Trace 的之前,我们先来学习一下 MySQL 是如何选择众多执行计划的 。
MySQL 会使用一个基于成本(cost)的优化器对执行计划进行选择 。每个执行计划的成本大致反应了该计划查询所需要的资源,主要因素是计算查询时将要访问的行数 。优化器主要根据从存储引擎获取数据的统计数据和数据字典中元数据信息来做出判断 。它会决定是使用全表扫描或者使用某一个索引进行扫描,也会决定表 join的顺序 。优化器的作用如下图所示 。

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

文章插图
 
优化器会为每个操作标上成本,这些成本的基准单位或最小值是从磁盘读取随机数据页的成本,其他操作的成本都是它的倍数 。所以优化器可以根据每个执行计划的所有操作为其计算出总的成本,然后从众多执行计划中,选取成本最小的来最终执行 。
【100% 展示 MySQL 语句执行的神器-Optimizer Trace】既然是基于统计数据来进行标记成本,就总会有样本无法正确反映整体的情况,这也是 MySQL 优化器有时做出错误优化的重要原因之一 。
Optimizer Trace 的基本使用首先,我们来看一下具体如何使用 Optimizer Trace 。默认情况下,该功能是关闭的,大家可以使用如下方式打开该功能,然后执行自己需要分析的 SQL 语句,然后再从 INFORMATION


    推荐阅读