关于mysql:MySQL源码解析之执行计划

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