在上一篇文章《用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 語句，然后再從 INFORMATIONSCHEMA 的 OPTIMIZERTRACE中查找到該 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 找到其 joinoptimization 中 rangeanalysis 相關數據，它會展示 where 從句范圍查詢過程中索引的選擇情況

由上圖可以看出，MySQL 對比了全表掃描和使用 val 作為索引兩個方案的成本，最后發現雖然全表掃描需要掃描更多的行，但是成本更低。所以選擇了全表掃描的執行方案。

這是為什么呢？明明使用 val 索引可以少掃描 4 行。這其實涉及 InnoDB 中使用索引查詢數據行的原理。

Innodb引擎查詢記錄時在無法使用索引覆蓋(也就是需要查詢的數據多與索引值，比如該例子中，我要查name，而索引列是 val)的場景下，需要做回表操作獲取記錄的所需字段，也就是說，通過索引查出主鍵，再去查數據行，取出對應的列，這樣勢必是會多花費成本的。

所以在回表數據量比較大時，經常會出現 Mysql 對回表操作查詢代價預估代價過大而導致不使用索引的情況。

一般來說，當SQL 語句查詢超過表中超過大概五分之一的記錄且不能使用覆蓋索引時，會出現索引的回表代價太大而選擇全表掃描的現象。且這個比例隨著單行記錄的字節大小的增加而略微增大。

通過 range_analysis 中的相關數據也可以對 where 從句使用多個索引列，如何選擇執行時使用的索引的情況進行分析。

小節

終于，介紹了有關于 MySQL 語句執行分析的 explain 和 Optimizer Trace，下一篇，我們將分析具體的死鎖場景。