作者：Mutlis
CSDN & 阿里云 & 知乎 等平台优质作者，善于 Oracle & MySQL 等支流数据库系统的保护和治理等
本文起源：原创投稿
前言
对于 MySQL 5.6 以及之前的版本来说，查问优化器就像是一个黑盒子一样，你只能通过 EXPLAIN 语句查看到最初优化器决定应用的执行打算，却无奈晓得它为什么做这个决策。这对于一部分喜爱刨根问底的⼩搭档来说几乎是劫难：“我就感觉应用其余的执行计划⽐ EXPLAIN 输入的这种计划强，凭什么优化器做的决定和我想的不一样呢？”这篇文章次要介绍应用 optimizer trace 查看优化器生成执行打算的整个过程。
optimizer trace 表的神奇效用
在 MySQL 5.6 以及之后的版本中，设计 MySQL 的大叔贴⼼的为这部分小伙伴提出了一个 optimizer trace 的性能，这个性能能够让咱们不便的查看优化器生成执行打算的整个过程，这个性能的开启与敞开由零碎变量 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)而后咱们就能够输出咱们想要查看优化过程的查问语句，当该查问语句执行实现后，就能够到 information_schema 数据库下的 OPTIMIZER_TRACE 表中查看残缺的优化过程。这个 OPTIMIZER_TRACE 表有 4 个列，别离是：
QUERY：示意咱们查问的语句；TRACE：示意优化过程的 JSON 格局⽂本；MISSING_BYTES_BEYOND_MAX_MEM_SIZE：因为优化过程可能会输入很多，如果超过某个限度时，多余的⽂本将不会被显示，这个字段展现了被疏忽的⽂本字节数；INSUFFICIENT_PRIVILEGES：示意是否没有权限查看优化过程，默认值是 0，只有某些非凡状况下才会是 1，咱们临时不关怀这个字段的值。
残缺的应用 optimizer trace 性能的步骤总结如下：
步骤一： 关上 optimizer trace 性能 (默认状况下它是敞开的)。
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.01 sec)
步骤二： 输出查问语句。
SELECT ...;步骤三： 从 optimizer_trace 表中查看上一个查问的优化过程。
SELECT * FROM information_schema.OPTIMIZER_TRACE;步骤四： 可能你还要察看其余语句执行的优化过程，反复上边的第 2、3 步。
步骤五： 当你停⽌查看语句的优化过程时，把 optimizer trace 性能敞开。
mysql> SET optimizer_trace="enabled=off";
Query OK, 0 rows affected (0.01 sec)当初咱们有一个搜寻条件比拟多的查问语句，它的执行打算如下：
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 个，那么为什么优化器最终抉择了 idx_key1 而不抉择其余的索引或者间接全表扫描呢？这时候就能够通过otpimzer trace 性能来查看优化器的具体工作过程：
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\G MySQL 可能会在之后的版本中增加更多的优化过程信息。不过芜杂之中其实还是蛮有法则的，优化过程大抵分为了三个阶段：
- prepare 阶段
- optimize 阶段
- execute 阶段
咱们所说的基于老本的优化次要集中在 optimize 阶段，对于单表查问来说，咱们次要关注 optimize 阶段的 "rows_estimation" 这个过程。这个过程深入分析了对单表查问的各种执行计划的老本，对于多表连贯查问来说，咱们更多须要关注 "considered_execution_plans" 这个过程，这个过程里会写明各种不同的连贯形式所对应的老本。反正优化器最终会抉择老本最低的那种计划来作为最终的执行打算，也就是咱们应用 EXPLAIN 语句所展现出的那种计划。
最初，咱们为感兴趣的小伙伴展现一下通过查问 OPTIMIZER_TRACE 表失去的输入（我应用 # 后追随正文的模式为大家解释了优化过程中的一些比拟重要的点，倡议用电脑屏幕观看）：
*************************** 1. row ***************************
# 剖析的查问语句是什么
QUERY: SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc'
# 优化的具体过程
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 的范畴区间
"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,# 应用该索引获取的记录条数
"cost": 3544.01,# 应用该索引的老本
"chosen": false, # 应用该索引的老本
"cause": "cost" # 因为老本太大所以不抉择该索引
},
{
# 应用 idx_key1 的老本剖析
"index": "idx_key1",
# 应用 idx_key1 的范畴区间
"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 的范畴区间
"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 最优的拜访办法
"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
}
}
}
]
},
{
# 剖析各种可能的执行打算
#（对多表查问这可能有很多种不同的计划，单表查问的计划上边曾经剖析过了，间接选取 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')))"
}
]
},
{
# 再稍稍的改良一下执行打算
"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": []}
}
]
}
# 因优化过程文本太多而抛弃的文本字节大小，值为 0 时示意并没有抛弃
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0
# 权限字段
INSUFFICIENT_PRIVILEGES: 0
1 row in set (0.01 sec)
ERROR:
No query specified大家看到这个输入的第一感觉就是这文本也太多了点吧，其实这只是优化器执行过程中的一小部分。
如果有小伙伴对应用 EXPLAIN 语句展现出的对某个查问的执行打算很不了解，大家能够尝试应用 optimizer trace 性能来具体理解每一种执行计划对应的老本，置信这个性能能让大家更深刻的理解 MySQL 查问优化器。
对于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，反对多场景审核，反对标准化上线流程，原生反对 MySQL 审核且数据库类型可扩大的 SQL 审核工具。
SQLE 获取
| 类型 | 地址 |
|---|---|
| 版本库 | https://github.com/actiontech/sqle |
| 文档 | https://actiontech.github.io/sqle-docs-cn/ |
| 公布信息 | https://github.com/actiontech/sqle/releases |
| 数据审核插件开发文档 | https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_audit… |
提交无效 pr，高质量 issue，将获赠面值 200-500 元（具体面额根据品质而定）京东卡以及爱可生开源社区精美周边！更多对于 SQLE 的信息和交换，请退出官网 QQ 交换群：637150065