一文了解MySQL Optimizer Trace的神奇功能
作者：Mutlis
CSDN & 阿里云 & 知乎 等平臺(tái)優(yōu)質(zhì)作者，擅長Oracle & MySQL等主流數(shù)據(jù)庫系統(tǒng)的維護(hù)和管理等
對(duì)于 MySQL 5.6 以及之前的版本來說，查詢優(yōu)化器就像是一個(gè)黑盒子一樣，你只能通過 EXPLAIN 語句查看到最后優(yōu)化器決定使用的執(zhí)行計(jì)劃，卻無法知道它為什么做這個(gè)決策。
這對(duì)于一部分喜歡刨根問底的?伙伴來說簡直是災(zāi)難：“我就覺得使用其他的執(zhí)行方案? EXPLAIN 輸出的這種方案強(qiáng)，憑什么優(yōu)化器做的決定和我想的不一樣呢？”這篇文章主要介紹使用 optimizer trace 查看優(yōu)化器生成執(zhí)行計(jì)劃的整個(gè)過程。
optimizer trace 表的神奇功效在 MySQL 5.6 以及之后的版本中，設(shè)計(jì) MySQL 的大叔貼?的為這部分小伙伴提出了一個(gè) optimizer trace 的功能，這個(gè)功能可以讓我們方便的查看優(yōu)化器生成執(zhí)行計(jì)劃的整個(gè)過程，這個(gè)功能的開啟與關(guān)閉由系統(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，表明這個(gè)功能默認(rèn)是關(guān)閉的。
小提示：
one_line 的值是控制輸出格式的，如果為 on 那么所有輸出都將在一行中展示，不適合?閱讀，所以我們就保持其默認(rèn)值為 off 吧。
如果想打開這個(gè)功能，必須?先把 enabled 的值改為 on，就像這樣：
mysql> SET optimizer_trace='enabled=on';Query OK, 0 rows affected (0.00 sec)然后我們就可以輸入我們想要查看優(yōu)化過程的查詢語句，當(dāng)該查詢語句執(zhí)行完成后，就可以到 information_schema 數(shù)據(jù)庫下的 OPTIMIZER_TRACE 表中查看完整的優(yōu)化過程。
這個(gè) OPTIMIZER_TRACE 表有 4 個(gè)列，分別是：
QUERY：表示我們查詢的語句；TRACE：表示優(yōu)化過程的 JSON 格式?本；MISSING_BYTES_BEYOND_MAX_MEM_SIZE：由于優(yōu)化過程可能會(huì)輸出很多，如果超過某個(gè)限制時(shí)，多余的?本將不會(huì)被顯示，這個(gè)字段展示了被忽略的?本字節(jié)數(shù)；INSUFFICIENT_PRIVILEGES：表示是否沒有權(quán)限查看優(yōu)化過程，默認(rèn)值是 0，只有某些特殊情況下才會(huì)是 1，我們暫時(shí)不關(guān)心這個(gè)字段的值。完整的使用 optimizer trace 功能的步驟總結(jié)步驟一： 打開 optimizer trace 功能 (默認(rèn)情況下它是關(guān)閉的)。
mysql> SET optimizer_trace='enabled=on';Query OK, 0 rows affected (0.01 sec)步驟二： 輸入查詢語句。
SELECT ...;步驟三： 從 optimizer_trace 表中查看上一個(gè)查詢的優(yōu)化過程。
SELECT * FROM information_schema.OPTIMIZER_TRACE;步驟四： 可能你還要觀察其他語句執(zhí)行的優(yōu)化過程，重復(fù)上邊的第 2、3步。
步驟五： 當(dāng)你停?查看語句的優(yōu)化過程時(shí)，把 optimizer trace 功能關(guān)閉。
mysql> SET optimizer_trace='enabled=off';Query OK, 0 rows affected (0.01 sec)現(xiàn)在我們有一個(gè)搜索條件比較多的查詢語句，它的執(zhí)行計(jì)劃如下：
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個(gè)，那么為什么優(yōu)化器最終選擇了idx_key1而不選擇其他的索引或者直接全表掃描呢？這時(shí)候就可以通過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 可能會(huì)在之后的版本中添加更多的優(yōu)化過程信息。不過雜亂之中其實(shí)還是蠻有規(guī)律的，優(yōu)化過程大致分為了三個(gè)階段：
prepare 階段optimize 階段execute 階段我們所說的基于成本的優(yōu)化主要集中在 optimize 階段，對(duì)于單表查詢來說，我們主要關(guān)注 optimize 階段的 "rows_estimation" 這個(gè)過程。這個(gè)過程深入分析了對(duì)單表查詢的各種執(zhí)行方案的成本，對(duì)于多表連接查詢來說，我們更多需要關(guān)注 "considered_execution_plans" 這個(gè)過程，這個(gè)過程里會(huì)寫明各種不同的連接方式所對(duì)應(yīng)的成本。反正優(yōu)化器最終會(huì)選擇成本最低的那種方案來作為最終的執(zhí)行計(jì)劃，也就是我們使用 EXPLAIN 語句所展現(xiàn)出的那種方案。
最后，我們?yōu)楦信d趣的小伙伴展示一下通過查詢 OPTIMIZER_TRACE 表得到的輸出（我使用#后跟隨注釋的形式為大家解釋了優(yōu)化過程中的一些比較重要的點(diǎn)，建議用電腦屏幕觀看）：
*************************** 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': [{# 等值傳遞轉(zhuǎn)換 '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`))'},{# 常量傳遞轉(zhuǎn)換 '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': [ ] }, { # 預(yù)估不同單表訪問方法的訪問成本 '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' # 因?yàn)槌杀咎笏圆贿x擇該索引 }, { # 使用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' } }, # 對(duì)于上述單表查詢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í)行計(jì)劃 #（對(duì)多表查詢這可能有很多種不同的方案，單表查詢的方案上邊已經(jīng)分析過了，直接選取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')))' } ] }, { # 再稍稍的改進(jìn)一下執(zhí)行計(jì)劃 '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時(shí)表示并沒有丟棄MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0# 權(quán)限字段INSUFFICIENT_PRIVILEGES: 01 row in set (0.01 sec)ERROR: No query specified大家看到這個(gè)輸出的第一感覺就是這文本也太多了點(diǎn)吧，其實(shí)這只是優(yōu)化器執(zhí)行過程中的一小部分。
如果有小伙伴對(duì)使用 EXPLAIN 語句展示出的對(duì)某個(gè)查詢的執(zhí)行計(jì)劃很不理解，大家可以嘗試使用 optimizer trace 功能來詳細(xì)了解每一種執(zhí)行方案對(duì)應(yīng)的成本，相信這個(gè)功能能讓大家更深入的了解 MySQL 查詢優(yōu)化器。
關(guān)于 SQLE愛可生開源社區(qū)的 SQLE 是一款面向數(shù)據(jù)庫使用者和管理者，支持多場(chǎng)景審核，支持標(biāo)準(zhǔn)化上線流程，原生支持 MySQL 審核且數(shù)據(jù)庫類型可擴(kuò)展的 SQL 審核工具。
SQLE 獲取類型地址版本庫https://github.com/actiontech/sqle文檔https://actiontech.github.io/sqle-docs-cn/發(fā)布信息https://github.com/actiontech/sqle/releases數(shù)據(jù)審核插件開發(fā)文檔https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_audit...以上就是一文了解MySQL Optimizer Trace的神奇功能的詳細(xì)內(nèi)容，更多關(guān)于MySQL Optimizer Trace功能的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！
網(wǎng)公網(wǎng)安備