关于MySQL分区表的一个性能BUG(分区表字段) 您所在的位置:网站首页 查看分区表分区数据 关于MySQL分区表的一个性能BUG(分区表字段)

关于MySQL分区表的一个性能BUG(分区表字段)

2023-05-16 01:42| 来源: 网络整理| 查看: 265

目录二、使用pt-pmap进行栈分析三、关于本列中瓶颈点的分析四、分区表中多次建立template的情况五、关于一个特殊的流程六、问题模拟七、总结一、问题描述

最近遇到一个问题,也就是使用分区表进行数据查询/加载的时候比普通表的性能下降了约50%,主要瓶颈出现在CPU,既然是CPU瓶颈理所当然的我们可以采集perf top -a -g和pstack来寻找性能瓶颈所在,同时和普通表进行对比,发现CPU主要耗在函数build_template_field上如下图:

二、使用pt-pmap进行栈分析

为了和perf top -g -a进行相互印证,我们同时获取了当时的pstack,由于线程较多为了方便获取有用的信息我们通过pt-pmap进行了格式化如下:

格式化后我们提出掉空闲的等待栈,发现大量的如上,这也和perf top -a -g中的表现进行了相互印证。

三、关于本列中瓶颈点的分析

我们看到这里大量的cpu耗在

ha_innobase::build_template ->build_template_field ->dict_col_get_clust_pos

对于template来讲,其几乎是和特定的一次的查询进行绑定的,也就是普通的语句至少需要一个template。其结构为row_prebuilt_t,包含查询元组,查询的表,查询用到的索引,事务相关信息,持久化游标,MySQL层查询行的长度,自增信息,ICP相关信息,mysql_row_templ_t结构等信息。其中mysql_row_templ_t 这个信息就是每个字段一个,主要作用记录的是MySQL层feild信息和Innodb层columns信息的相关属性,用于快速转换一行记录在MySQL层和Innodb层之间转换。为了初始化mysql_row_templ_t 就出现了上面的逻辑,

大概逻辑如下:

循环表中每个字段(一层循环)ha_innobase::build_template 是否为需要访问的字段 build_template_needs_field 这里包含查询和写入的所有字段,需要访问的字段越多越慢 如果不是则不作继续循环 如果需要访问 build_template_field(mysql_row_templ_t结构体填充) 循环主键的每个字段(二层循环) 包含伪列,主键就是表的里面全部字段,表中字段越多越慢)dict_col_get_clust_pos 确认本字段在主键的位置 pos0 主键 pos1 DB_TRX_ID pos2 DB_ROLL_PTR pos3 开始为用户其他字段 循环索引的每个字段(二层循环,但是索引字段一般不会太多,因此这里不会慢)dict_index_t::get_col_pos 确认本字段在索引的位置,如果没有则返回NULL 返回pos 比如 主键 id1 二级索引 id2 id3 二级索引为 pos0 id2 pos1 id3 pos2 id1 继续完成其他属性比如mysql null位图,mysql显示长度,mysql字符集等等

这里我们看到这里实际上有2层循环,也就是循环套循环(时间复杂度O(M×N)),而循环影响最大的有2个地方:

第一层,表中字段的多少 第二层,需要访问的字段(读和写都算)在主键(也就是全部字段)中循环

这里也就是为什么这里会慢的原因。但是template通常不会一个查询进行多次建立,比如一个普通表的大查询,只有在语句第一次进行数据定位之前会进行建立,这就不得不说这是分区表和普通表的对比中一个特殊的地方了。下面描述一下。

四、分区表中多次建立template的情况

假设我们有如下的分区表:

create table t( id1 int, id2 int, primary key(id1), key(id2) )engine=innodb partition by range(id1)( partition p0 values less than(100), partition p1 values less than(200), partition p2 values less than(300)); insert into t values(1,1); insert into t values(101,1); insert into t values(201,1); insert into t values(2,2); insert into t values(3,2); insert into t values(4,2); insert into t values(7,2); insert into t values(8,2); insert into t values(9,2); insert into t values(10,2);

我们使用语句"select * from t where id2=1",显然id2是二级索引,由于MySQL全部都是local分区的二级索引,因此这里值分别分布在3个分区中,对于这样一个语句在本该是普通表通过上次定位后的位置继续访问(next_same)的时候,通过封装分区表的方法,将其改为了index read再次定位,而我们可以清楚的看到这里是scan next partition,其part=1这是第二个分区了,也就是我们的p1(第一个为0)

这样template需要每个分区(scan next partition)都进行重建,这样就出现了我们上面的问题。这个其实也可以理解,新的分区是新的innodb文件,这样上次定位的持久化游标实际已经没有什么用了,就相当于一次新的表访问。这里在是否进行template建立还有一个判断如下:

if (m_prebuilt->sql_stat_start) { build_template(false); }

而m_prebuilt->sql_stat_start除了在语句开始的时候设置为true,每次更换分区依旧会设置为true如下:

ha_innopart::set_partition: m_prebuilt->sql_stat_start = m_sql_stat_start_parts.test(part_id);

五、关于一个特殊的流程

在我们的故障pstack中还有一个栈如下:

这个栈实际并不完整,但是其中出现了Partition_helper::handle_ordered_index_scan,这个函数实际上和分区表的排序有关,如果我们考虑这样一种情况,对于二级索引select max(id2) from t,那么需要首先访问每个分区获取其中的最大值然后对比每个分区的最大值,得到最终的结果,而MySQL则采用优先队列进行处理,这应该是就是本函数完成的部分功能(没仔细去看)。其次我们先出现了QUICK_RANGE_SELECT这是范围查询会用到的,那么我们构造如下:

select * from t where id2

版权声明:本站文章来源标注为YINGSOO的内容版权均为本站所有,欢迎引用、转载,请保持原文完整并注明来源及原文链接。禁止复制或仿造本网站,禁止在非www.yingsoo.com所属的服务器上建立镜像,否则将依法追究法律责任。本站部分内容来源于网友推荐、互联网收集整理而来,仅供学习参考,不代表本站立场,如有内容涉嫌侵权,请联系alex-e#qq.com处理。



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

      专题文章
        CopyRight 2018-2019 实验室设备网 版权所有