100%展示MySQL語句執(zhí)行的神器-Optimizer Trace

在上一篇文章《用Explain 命令分析 MySQL 的 SQL 執(zhí)行》中，我們講解了 Explain 命令的詳細使用。但是它只能展示 SQL 語句的執(zhí)行計劃，無法展示為什么一些其他的執(zhí)行計劃未被選擇，比如說明明有索引，但是為什么查詢時未使用索引等。為此，MySQL 提供了 Optimizer Trace 功能，讓我們能更加詳細的了解 SQL 語句執(zhí)行的所有分析，優(yōu)化和選擇過程。

如果您想更深入地了解為什么選擇某個查詢計劃，那么優(yōu)化器跟蹤非常有用。雖然 EXPLAIN 顯示選定的計劃，但Optimizer Trace 能顯示為什么選擇計劃：您將能夠看到替代計劃，估計成本以及做出的決策。本篇文章會詳細講解 Optimizer Trace 展示的所有相關(guān)信息，并且會輔之一些具體使用案例。

基于成本的執(zhí)行計劃

在了解 Optimizer Trace 的之前，我們先來學(xué)習(xí)一下 MySQL 是如何選擇眾多執(zhí)行計劃的。

MySQL 會使用一個基于成本(cost)的優(yōu)化器對執(zhí)行計劃進行選擇。每個執(zhí)行計劃的成本大致反應(yīng)了該計劃查詢所需要的資源，主要因素是計算查詢時將要訪問的行數(shù)。優(yōu)化器主要根據(jù)從存儲引擎獲取數(shù)據(jù)的統(tǒng)計數(shù)據(jù)和數(shù)據(jù)字典中元數(shù)據(jù)信息來做出判斷。它會決定是使用全表掃描或者使用某一個索引進行掃描，也會決定表 join的順序。優(yōu)化器的作用如下圖所示。

優(yōu)化器會為每個操作標(biāo)上成本，這些成本的基準(zhǔn)單位或最小值是從磁盤讀取隨機數(shù)據(jù)頁的成本，其他操作的成本都是它的倍數(shù)。所以優(yōu)化器可以根據(jù)每個執(zhí)行計劃的所有操作為其計算出總的成本，然后從眾多執(zhí)行計劃中，選取成本最小的來最終執(zhí)行。

既然是基于統(tǒng)計數(shù)據(jù)來進行標(biāo)記成本，就總會有樣本無法正確反映整體的情況，這也是 MySQL 優(yōu)化器有時做出錯誤優(yōu)化的重要原因之一。

Optimizer Trace 的基本使用

首先，我們來看一下具體如何使用 Optimizer Trace。默認情況下，該功能是關(guān)閉的，大家可以使用如下方式打開該功能，然后執(zhí)行自己需要分析的 SQL 語句，然后再從 INFORMATIONSCHEMA 的 OPTIMIZERTRACE中查找到該 SQL 語句執(zhí)行優(yōu)化的相關(guān)信息。

   

    
# 1. 打開optimizer trace功能 (默認情況下它是關(guān)閉的):
    
SET optimizer_trace="enabled=on";
    
SELECT ...; # 這里輸入你自己的查詢語句
    
SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
    
# 當(dāng)你停止查看語句的優(yōu)化過程時，把optimizer trace功能關(guān)閉
    
SET optimizer_trace="enabled=off";
   

這個 OPTIMIZER_TRACE 表有4個列，如下所示：

• QUERY：表示我們的查詢語句。

• TRACE：表示優(yōu)化過程的JSON格式文本。

• MISSING_BYTES_BEYOND_MAX_MEM_SIZE：由于優(yōu)化過程可能會輸出很多，如果超過某個限制時，多余的文本將不會被顯示，這個字段展示了被忽略的文本字節(jié)數(shù)。

• INSUFFICIENT_PRIVILEGES：表示是否沒有權(quán)限查看優(yōu)化過程，默認值是0，只有某些特殊情況下才會是?1，我們暫時不關(guān)心這個字段的值。

其中，信息最多也最為重要的就是第二列 TRACE，它也是我們后續(xù)分析的重點。

TRACE 列的基本格式

TRACE 列的內(nèi)容是一個超級大的 JSON 數(shù)據(jù)，直接展開然后一條一條解析估計能看到大伙腦殼疼。

所以，我們先來看一下這坨大 JSON 的骨架。它有三大塊內(nèi)容，也代表著 SQL 語句處理的三個階段，分別為準(zhǔn)備階段，優(yōu)化階段和執(zhí)行階段。

接下來，我們詳細介紹一個案例，在案例中介紹涉及到的具體字段和含義。

為什么查詢未走索引而是全表掃描

首先，SQL 語句查詢不使用索引的情況有很多，我們這里只討論因為基于成本的優(yōu)化器認為全表查詢執(zhí)行計劃的成本低于走索引執(zhí)行計劃的情況。

如下圖這個場景，明明 val 列上有索引，并且 val 現(xiàn)存值也有一定差異性，為什么沒有使用索引進行查詢呢？

我們按照上文使用 Optimizer Trace 找到其 joinoptimization 中 rangeanalysis 相關(guān)數(shù)據(jù)，它會展示 where 從句范圍查詢過程中索引的選擇情況

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

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

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

所以在回表數(shù)據(jù)量比較大時，經(jīng)常會出現(xiàn) Mysql 對回表操作查詢代價預(yù)估代價過大而導(dǎo)致不使用索引的情況。

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

通過 range_analysis 中的相關(guān)數(shù)據(jù)也可以對 where 從句使用多個索引列，如何選擇執(zhí)行時使用的索引的情況進行分析。

小節(jié)

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

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝