在上一篇文章《用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，下一篇，我們將分析具體的死鎖場景。
