共计 3154 个字符,预计需要花费 8 分钟才能阅读完成。
MySQL 源码解析之执行打算
- MySQL 执行打算介绍
- MySQL 执行打算代码概览
- MySQL 执行打算总结
一、MySQL 执行打算介绍
在 MySQL 中,执行打算的实现是基于 JOIN
和QEP_TAB
这两个对象。其中 JOIN 类示意一个查问语句块的优化和执行,每个 select 查问语句(即 Query_block 对象)在解决的时候,都会被当做 JOIN 对象,其定义在sql/sql_optimizer.h
。
QEP_TAB
是 Query Execution Plan Table
的缩写,这里的表 Table 对象次要蕴含物化表、长期表、派生表、常量表等。JOIN::optimize()
是优化执行器的对立入口,在这里会把一个查问语句块 Query_block
最终优化成QEP_TAB
。
在 MySQL-8.0.22 版本之后,又引入拜访形式AccessPath
和执行迭代器 Iterator
对象,再联合 JOIN 和 QEP_TAB 对象,最终失去整个解析打算的执行门路。
二、MySQL 执行打算代码概览
本文次要 基于 MySQL-8.0.25 版本,进行阐明。
优化器的入口函数:bool JOIN::optimize()
,对应代码文件sql/sql_optimizer.cc
。
// 次要性能是把一个查问块 Query_block 优化成一个 QEP_TAB,失去 AccessPath
bool JOIN::optimize() {
...
// 上面次要是为了能够借助 INFORMATION_SCHEMA.OPTIMIZER_TRACE 表,跟踪优化器的执行状态和执行步骤
Opt_trace_context *const trace = &thd->opt_trace;
Opt_trace_object trace_wrapper(trace);
Opt_trace_object trace_optimize(trace, "join_optimization");
trace_optimize.add_select_number(Query_block->select_number);
Opt_trace_array trace_steps(trace, "steps");
...
// 窗口函数拆卸优化
if (has_windows && Window::setup_windows2(thd, m_windows))
...
// 拷贝 Query_block 上的条件正本到 JOIN 构造关联的成员对象,为后续优化做筹备
if (Query_block->get_optimizable_conditions(thd, &where_cond, &having_cond))
...
// 统计形象语法树中的叶节点表,其中 leaf_tables 是在 Query_block::setup_tables 中进行拆卸
tables_list = Query_block->leaf_tables;
...
// 分区裁剪
if (Query_block->partitioned_table_count && prune_table_partitions()) {
...
// 尝试把聚合函数 COUNT()、MIN()、MAX()对应的值,替换成常量
if (optimize_aggregated_query(thd, Query_block, *fields, where_cond,
&outcome)) {
...
// 采纳超图算法生成执行打算,留神超图算法通过 set optimizer_switch="hypergraph_optimizer=on" 形式启用
if (thd->lex->using_hypergraph_optimizer) {FindBestQueryPlan(thd, Query_block, /*trace=*/nullptr);
// 如果 Join 优化器是超图算法,解决完结间接返回
return false;
}
...
上面代码次要波及 Join 优化器连贯形式为 左深树 的状况,次要用到 join_tab
数组来进行组织关联
依据代价计算表的连贯形式,外围函数make_join_plan()
,实现非常复杂。比拟要害的函数是bool Optimize_table_order::choose_table_order()
其次要思维是通过贪心搜寻Optimize_table_order::greedy_search
,依据最小的连贯代价,进行无限的穷举搜寻(细节参考 Optimize_table_order::best_extension_by_limited_search)
最终找到近似最优解的连贯排列组合
if (make_join_plan()) {
...
// 语句块谓词条件下推,晋升过滤性能
if (make_join_Query_block(this, where_cond)) {
...
// 优化 order by/distinct 语句
if (optimize_distinct_group_order()) return true;
...
// 调配 QEP_TAB 数组
if (alloc_qep(tables)) return (error = 1); /* purecov: inspected */
...
// 执行打算细化,优化子查问和半连贯的状况,具体策略能够参考 mariadb 的文档:// https:// mariadb.com/kb/en/optimization-strategies/
// 要害代码是 setup_semijoin_dups_elimination,次要对半连贯关联的策略进行拆卸
if (make_join_readinfo(this, no_jbuf_after))
...
// 为解决 group by/order by 创立开拓长期表空间
if (make_tmp_tables_info()) return true;
...
// 生成拜访形式 AccessPath,供后续迭代器 Iterator 拜访应用
create_access_paths();
...
return false;
}
三、MySQL 执行打算总结
MySQL 的执行打算是整个数据库最外围的模块,其代码也在一直地迭代更新过程中。执行打算中优化器的好坏和背地的搜寻策略、数学模型严密相干。MySQL 反对的搜寻策略有穷举搜寻、贪心搜寻,对应的 Join 优化器有左深树算法和超图算法,整个优化过程次要是基于 CBO 策略进行优化。
执行打算运行的过程,实际上就是一个动静布局的过程 。这个过程的优劣,快慢决定了 MySQL 和支流商业数据库的差距。只有深刻地了解 MySQL 优化器的运行原理,能力帮忙咱们踊跃无效地摸索更高性能优化的可能。
最初因为笔者常识程度无限,疏漏之处,还望斧正。
Enjoy GreatSQL :)
文章举荐:
面向金融级利用的 GreatSQL 正式开源
Changes in GreatSQL 8.0.25 (2021-8-18)
MGR 及 GreatSQL 资源汇总
GreatSQL MGR FAQ
在 Linux 下源码编译装置 GreatSQL/MySQL
## 对于 GreatSQL
GreatSQL 是由万里数据库保护的 MySQL 分支,专一于晋升 MGR 可靠性及性能,反对 InnoDB 并行查问个性,是实用于金融级利用的 MySQL 分支版本。
Gitee:
https://gitee.com/GreatSQL/GreatSQL
GitHub:
https://github.com/GreatSQL/GreatSQL
Bilibili:
https://space.bilibili.com/1363850082/favlist
微信 &QQ 群:
QQ 群:533341697
微信群:可搜寻增加 GreatSQL 社区助手
微信好友,发送验证信息“加群”退出 GreatSQL/MGR 交换微信群
GreatSQL 社区助手:wanlidbc