一文了解MySQL Optimizer Trace的神奇功能
更新時間：2023年06月19日 11:18:56 作者：愛可生云數(shù)據庫
這篇文章主要為大家介紹了一文了解MySQL Optimizer Trace的神奇功能詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
前言
作者：Mutlis
CSDN & 阿里云 & 知乎 等平臺優(yōu)質作者，擅長Oracle & MySQL等主流數(shù)據庫系統(tǒng)的維護和管理等
對于 MySQL 5.6 以及之前的版本來說，查詢優(yōu)化器就像是一個黑盒子一樣，你只能通過 EXPLAIN 語句查看到最后優(yōu)化器決定使用的執(zhí)行計劃，卻無法知道它為什么做這個決策。
這對于一部分喜歡刨根問底的?伙伴來說簡直是災難：“我就覺得使用其他的執(zhí)行方案? EXPLAIN 輸出的這種方案強，憑什么優(yōu)化器做的決定和我想的不一樣呢？”這篇文章主要介紹使用 optimizer trace 查看優(yōu)化器生成執(zhí)行計劃的整個過程。
optimizer trace 表的神奇功效
在 MySQL 5.6 以及之后的版本中，設計 MySQL 的大叔貼?的為這部分小伙伴提出了一個 optimizer trace 的功能，這個功能可以讓我們方便的查看優(yōu)化器生成執(zhí)行計劃的整個過程，這個功能的開啟與關閉由系統(tǒng)變量 optimizer_trace 決定，我們看一下：
mysql> show variables like 'optimizer_trace'; +-----------------+--------------------------+ | Variable_name | Value | +-----------------+--------------------------+ | optimizer_trace | enabled=off,one_line=off | +-----------------+--------------------------+ 1 row in set (0.01 sec)
可以看到 enabled 值為 off，表明這個功能默認是關閉的。
小提示：
one_line 的值是控制輸出格式的，如果為 on 那么所有輸出都將在一行中展示，不適合?閱讀，所以我們就保持其默認值為 off 吧。
如果想打開這個功能，必須?先把 enabled 的值改為 on，就像這樣：
mysql> SET optimizer_trace="enabled=on"; Query OK, 0 rows affected (0.00 sec)
然后我們就可以輸入我們想要查看優(yōu)化過程的查詢語句，當該查詢語句執(zhí)行完成后，就可以到 information_schema 數(shù)據庫下的 OPTIMIZER_TRACE 表中查看完整的優(yōu)化過程。
這個 OPTIMIZER_TRACE 表有 4 個列，分別是：
QUERY：表示我們查詢的語句；TRACE：表示優(yōu)化過程的 JSON 格式?本；MISSING_BYTES_BEYOND_MAX_MEM_SIZE：由于優(yōu)化過程可能會輸出很多，如果超過某個限制時，多余的?本將不會被顯示，這個字段展示了被忽略的?本字節(jié)數(shù)；INSUFFICIENT_PRIVILEGES：表示是否沒有權限查看優(yōu)化過程，默認值是 0，只有某些特殊情況下才會是 1，我們暫時不關心這個字段的值。
完整的使用 optimizer trace 功能的步驟總結
步驟一： 打開 optimizer trace 功能 (默認情況下它是關閉的)。
mysql> SET optimizer_trace="enabled=on"; Query OK, 0 rows affected (0.01 sec)
步驟二： 輸入查詢語句。
SELECT ...;
步驟三： 從 optimizer_trace 表中查看上一個查詢的優(yōu)化過程。
SELECT * FROM information_schema.OPTIMIZER_TRACE;
步驟四： 可能你還要觀察其他語句執(zhí)行的優(yōu)化過程，重復上邊的第 2、3步。
步驟五： 當你停?查看語句的優(yōu)化過程時，把 optimizer trace 功能關閉。
mysql> SET optimizer_trace="enabled=off"; Query OK, 0 rows affected (0.01 sec)
現(xiàn)在我們有一個搜索條件比較多的查詢語句，它的執(zhí)行計劃如下：
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc';
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
| 1 | SIMPLE | s1 | NULL | range | idx_key2,idx_key1,idx_key3 | idx_key1 | 403 | NULL | 1 | 5.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
1 row in set, 1 warning (0.00 sec)可以看到該查詢可能使用到的索引有3個，那么為什么優(yōu)化器最終選擇了idx_key1而不選擇其他的索引或者直接全表掃描呢？這時候就可以通過otpimzer trace 功能來查看優(yōu)化器的具體工作過程：
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc';
Empty set (0.00 sec)
mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE\GMySQL 可能會在之后的版本中添加更多的優(yōu)化過程信息。不過雜亂之中其實還是蠻有規(guī)律的，優(yōu)化過程大致分為了三個階段：
- prepare 階段
- optimize 階段
- execute 階段
我們所說的基于成本的優(yōu)化主要集中在 optimize 階段，對于單表查詢來說，我們主要關注 optimize 階段的 "rows_estimation" 這個過程。這個過程深入分析了對單表查詢的各種執(zhí)行方案的成本，對于多表連接查詢來說，我們更多需要關注 "considered_execution_plans" 這個過程，這個過程里會寫明各種不同的連接方式所對應的成本。反正優(yōu)化器最終會選擇成本最低的那種方案來作為最終的執(zhí)行計劃，也就是我們使用 EXPLAIN 語句所展現(xiàn)出的那種方案。
最后，我們?yōu)楦信d趣的小伙伴展示一下通過查詢 OPTIMIZER_TRACE 表得到的輸出（我使用#后跟隨注釋的形式為大家解釋了優(yōu)化過程中的一些比較重要的點，建議用電腦屏幕觀看）：
*************************** 1. row ***************************
# 分析的查詢語句是什么
QUERY: SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc'
# 優(yōu)化的具體過程
TRACE: {
"steps": [
{
"join_preparation": { # prepare階段
"select#": 1,
"steps": [
{
"IN_uses_bisection": true
},
{
"expanded_query": "/* select#1 */ select `s1`.`id` AS `id`,`s1`.`key1` AS `key1`,`s1`.`key2` AS `key2`,`s1`.`key3` AS `key3`,`s1`.`key_part1` AS `key_part1`,`s1`.`key_part2` AS `key_part2`,`s1`.`key_part3` AS `key_part3`,`s1`.`common_field` AS `common_field` from `s1` where ((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and (`s1`.`common_field` = 'abc'))"
}
]
}
},
{
"join_optimization": { # optimize階段
"select#": 1,
"steps": [
{
"condition_processing": { # 處理搜索條件
"condition": "WHERE",
# 原始搜索條件
"original_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and (`s1`.`common_field` = 'abc'))",
"steps": [
{
# 等值傳遞轉換
"transformation": "equality_propagation",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
},
{
# 常量傳遞轉換
"transformation": "constant_propagation",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
},
{
# 去除沒用的條件
"transformation": "trivial_condition_removal",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
}
]
}
},
{
# 替換虛擬生成列
"substitute_generated_columns": {
}
},
{
# 表的依賴信息
"table_dependencies": [
{
"table": "`s1`",
"row_may_be_null": false,
"map_bit": 0,
"depends_on_map_bits": [
]
}
]
},
{
"ref_optimizer_key_uses": [
]
},
{
# 預估不同單表訪問方法的訪問成本
"rows_estimation": [
{
"table": "`s1`",
"range_analysis": {
"table_scan": {
"rows": 20250,
"cost": 2051.35
},
# 分析可能使用的索引
"potential_range_indexes": [
{
"index": "PRIMARY", # 主鍵不可用
"usable": false,
"cause": "not_applicable"
},
{
"index": "idx_key2",# idx_key2可能被使用
"usable": true,
"key_parts": [
"key2"
]
},
{
"index": "idx_key1", # idx_key1可能被使用
"usable": true,
"key_parts": [
"key1",
"id"
]
},
{
"index": "idx_key3", # idx_key3可能被使用
"usable": true,
"key_parts": [
"key3",
"id"
]
},
{
"index": "idx_key_part", # idx_key_part不可用
"usable": false,
"cause": "not_applicable"
}
],
"setup_range_conditions": [
],
"group_index_range": {
"chosen": false,
"cause": "not_group_by_or_distinct"
},
"skip_scan_range": {
"potential_skip_scan_indexes": [
{
"index": "idx_key2",
"usable": false,
"cause": "query_references_nonkey_column"
},
{
"index": "idx_key1",
"usable": false,
"cause": "query_references_nonkey_column"
},
{
"index": "idx_key3",
"usable": false,
"cause": "query_references_nonkey_column"
}
]
},
# 分析各種可能使用的索引的成本
"analyzing_range_alternatives": {
"range_scan_alternatives": [
{
# 使用idx_key2的成本分析
"index": "idx_key2",
# 使用idx_key2的范圍區(qū)間
"ranges": [
"NULL < key2 < 1000000"
],
"index_dives_for_eq_ranges": true,# 是否使用index dive
"rowid_ordered": false,# 使用該索引獲取的記錄是否按照主鍵排序
"using_mrr": false, # 是否使用mrr
"index_only": false, # 是否是索引覆蓋訪問
"in_memory": 1,
"rows": 10125,# 使用該索引獲取的記錄條數(shù)
"cost": 3544.01,# 使用該索引的成本
"chosen": false, # 使用該索引的成本
"cause": "cost" # 因為成本太大所以不選擇該索引
},
{
# 使用idx_key1的成本分析
"index": "idx_key1",
# 使用idx_key1的范圍區(qū)間
"ranges": [
"'z' < key1"
],
"index_dives_for_eq_ranges": true,# 同上
"rowid_ordered": false,# 同上
"using_mrr": false,# 同上
"index_only": false,# 同上
"in_memory": 1,
"rows": 1,# 同上
"cost": 0.61,# 同上
"chosen": true# 是否選擇該索引
},
{
# 使用idx_key3的成本分析
"index": "idx_key3",
# 使用idx_key3的范圍區(qū)間
"ranges": [
"key3 = 'aa'",
"key3 = 'bb'",
"key3 = 'cb'"
],
"index_dives_for_eq_ranges": true,# 同上
"rowid_ordered": false,# 同上
"using_mrr": false,# 同上
"index_only": false,# 同上
"in_memory": 1,
"rows": 3,# 同上
"cost": 1.81,# 同上
"chosen": false,# 同上
"cause": "cost"# 同上
}
],
# 分析使用索引合并的成本
"analyzing_roworder_intersect": {
"usable": false,
"cause": "too_few_roworder_scans"
}
},
# 對于上述單表查詢s1最優(yōu)的訪問方法
"chosen_range_access_summary": {
"range_access_plan": {
"type": "range_scan",
"index": "idx_key1",
"rows": 1,
"ranges": [
"'z' < key1"
]
},
"rows_for_plan": 1,
"cost_for_plan": 0.61,
"chosen": true
}
}
}
]
},
{
# 分析各種可能的執(zhí)行計劃
#（對多表查詢這可能有很多種不同的方案，單表查詢的方案上邊已經分析過了，直接選取idx_key1就好）
"considered_execution_plans": [
{
"plan_prefix": [
],
"table": "`s1`",
"best_access_path": {
"considered_access_paths": [
{
"rows_to_scan": 1,
"access_type": "range",
"range_details": {
"used_index": "idx_key1"
},
"resulting_rows": 1,
"cost": 0.71,
"chosen": true
}
]
},
"condition_filtering_pct": 100,
"rows_for_plan": 1,
"cost_for_plan": 0.71,
"chosen": true
}
]
},
{
"attaching_conditions_to_tables": {
"original_condition": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))",
"attached_conditions_computation": [
],
"attached_conditions_summary": [
{
"table": "`s1`",
"attached": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
}
},
{
# 嘗試給查詢添加一些其他的查詢條件
"finalizing_table_conditions": [
{
"table": "`s1`",
"original_table_condition": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))",
"final_table_condition ": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
},
{
# 再稍稍的改進一下執(zhí)行計劃
"refine_plan": [
{
"table": "`s1`",
"pushed_index_condition": "(`s1`.`key1` > 'z')",
"table_condition_attached": "((`s1`.`common_field` = 'abc') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
}
]
}
},
{
"join_execution": { # execute階段
"select#": 1,
"steps": [
]
}
}
]
}
# 因優(yōu)化過程文本太多而丟棄的文本字節(jié)大小，值為0時表示并沒有丟棄
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0
# 權限字段
INSUFFICIENT_PRIVILEGES: 0
1 row in set (0.01 sec)
ERROR:
No query specified大家看到這個輸出的第一感覺就是這文本也太多了點吧，其實這只是優(yōu)化器執(zhí)行過程中的一小部分。
如果有小伙伴對使用 EXPLAIN 語句展示出的對某個查詢的執(zhí)行計劃很不理解，大家可以嘗試使用 optimizer trace 功能來詳細了解每一種執(zhí)行方案對應的成本，相信這個功能能讓大家更深入的了解 MySQL 查詢優(yōu)化器。
關于 SQLE
愛可生開源社區(qū)的 SQLE 是一款面向數(shù)據庫使用者和管理者，支持多場景審核，支持標準化上線流程，原生支持 MySQL 審核且數(shù)據庫類型可擴展的 SQL 審核工具。
SQLE 獲取
以上就是一文了解MySQL Optimizer Trace的神奇功能的詳細內容，更多關于MySQL Optimizer Trace功能的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要介紹了Mysql中的單表最大記錄是多少問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-02-02
MySQL誤刪數(shù)據庫,造成了數(shù)據的丟失,這是非常尷尬的,但是有許多方案可以用來嘗試恢復丟失的數(shù)據庫,這篇文章主要給大家介紹了關于MySQL數(shù)據庫誤刪恢復的超詳細教程,需要的朋友可以參考下2024-03-03
這篇文章主要介紹了mysql分組后合并顯示一個字段的多條數(shù)據方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-01-01
本篇文章是對mysql時間處理函數(shù)進行了詳細的分析介紹，需要的朋友參考下2013-06-06
MySQL庫的操作之創(chuàng)建、刪除與管理數(shù)據庫
在數(shù)據庫管理中MySQL是一個廣泛應用的關系型數(shù)據庫管理系統(tǒng),它提供了豐富的命令行工具來執(zhí)行各種操作,這篇文章主要介紹了MySQL庫操作之創(chuàng)建、刪除與管理數(shù)據庫的相關資料,需要的朋友可以參考下2026-02-02
MySQL快速復制一張表的四種核心方法(包括表結構和數(shù)據)
本文詳細介紹了四種復制MySQL表（結構+數(shù)據）的方法,并對每種方法進行了對比分析,適用于不同場景和數(shù)據量的復制需求,特別是針對超大表（1億+行）和跨實例復制提供了具體的操作命令和注意事項,感興趣的朋友跟隨小編一起看看吧2025-12-12
文章介紹了存儲過程、變量、SQL編程、游標、存儲函數(shù)和觸發(fā)器的概念、使用方法和優(yōu)缺點,本文通過實例代碼對MySQL存儲過程、游標與觸發(fā)器相關知識介紹的非常詳細,感興趣的朋友一起看看吧2025-11-11
MySQL插入數(shù)據insert?ignore語法重復數(shù)據自動忽略
這篇文章主要給大家介紹了關于MySQL插入數(shù)據insert?ignore語法重復數(shù)據自動忽略的相關資料,最近工作中使用到了insert ignore into語法,感覺這個語法還是挺有用的,就記錄下來做個總結,需要的朋友可以參考下2023-08-08
下面小編就為大家?guī)硪黄狹ysql占用過高CPU時的優(yōu)化手段(必看)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-03-03
這篇文章主要為大家詳細介紹了linux下mysql忘記密碼的解決方法，具有一定的參考價值，感興趣的小伙伴們可以參考一下2018-08-08