Mysql Block Nested-Loop查询导致cpu利用率100%-
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Mysql Block Nested-Loop查询导致cpu利用率100%-相关的知识,希望对你有一定的参考价值。
参考技术A在客户的运营系统中,当客户执行某个条件的订单查询时,接口响应超时,同时服务器的cpu利用率高达100%
备注
上述俩种表中的数据量分别是:4万 和七万
对order_bill表建立索引,避免全表扫描
可以看到此时,已经使用了索引,同时mysql也不再使用Block Nested Loop
对order表也建立索引
可以看到,此时对order表的查询也不再走全面扫描,而是使用了索引
sql如下
mysql官方文档
stackoverflow
stackoverflow
博客
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 :)
《深入浅出MGR》视频课程
戳此小程序即可直达B站
https://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0
文章推荐:
想看更多技术好文,点个“在看”吧!
以上是关于Mysql Block Nested-Loop查询导致cpu利用率100%-的主要内容,如果未能解决你的问题,请参考以下文章
Block Nested-Loop 和 Batched Key Access
1122MySQL性能优化之 Nested Loop Join和Block Nested-Loop Join(BNL)
MySQL Block Nested-Loop Join(BNL)