选择Plan Cache功能,让您远离SQL语句执行慢烦恼

01/06 14:08
阅读数 42

SQL语句执行很慢?快来康康GaussDB(for MySQL)推出的这个小功能

在MySQL数据库中,SQL语句的执行大体分为解析、优化、执行几个主要的阶段。其中优化阶段会生成执行计划,执行阶段根据执行计划执行语句,返回结果。优化阶段要经历逻辑优化、物理优化等步骤,会消耗大量时间。

为提升SQL语句执行效率,华为云GaussDB(for MySQL)推出了Plan Cache功能,该功能对执行计划进行缓存,当相同的SQL语句多次执行时,可跳过优化阶段,直接进入执行阶段,从而提高SQL语句的执行速度。

1.原生MySQL VS GaussDB(for MySQL)

为了让大家有更直观的感受,我们对比了原生MySQL与GaussDB(for MySQL)的SQL语句执行场景,大家可以通过对比感知Plan Cache功能的妙处。

未使用Plan Cache功能的原生MySQL prepare 语句主要执行流程如下:

 

(1)parser阶段生成解析树,存放在stmt mem内存区域。

(2)optimize阶段对解析树进行查询优化,并生成执行计划(迭代器)。

(3)execute阶段根据执行计划,执行查询,返回查询结果。

(4)cleanup阶段对执行过程中生成的一些对象进行清理。

其中步骤1只有第一次执行查询时,需要执行。以后每次执行,使用保存在stmt mem区域中的解析树即可。

然而步骤2,每次执行时,都需要重新执行一遍,主要原因如下:

Ø 迭代器是根据optimize阶段生成的join、qeb_tab等对象产生的。在每次语句执行完成后,cleanup阶段会对其中一些对象进行清理。

Ø 这些对象的存储空间是从runtime mem内存区域分配的,每次语句执行完成后,会释放runtime mem内存。

启用Plan Cache后的GaussDB(for MySQL) prepare 语句主要执行流程如下:

 

(1)当查询第一次执行时,系统检查语句是否满足执行计划缓存的条件,并设置对应的状态标签。

(2)当查询第二次执行时,如果执行计划可以被缓存,则执行如下操作:

Ø 修改join、qep_tab等对象(生成迭代器时必需的对象)的存储分配策略,从stmt mem内存区域分配空间。

Ø Cleanup阶段进行部分清理,join、qep_tab等对象被保留,这样下一次执行时可重用。

(3)当语句第三次执行时,如果执行计划已被缓存,则跳过optimize阶段,直接进入execute阶段。


2.Plan Cache功能的参数替换与配置

因为执行计划(迭代器)中包含条件数据,所以每次执行时,需要替换缓存的执行计划参数,否则查询结果保持不变(为执行缓存时结果)。如下所示:


Const 

Range

 

参数配置方面:

Ø plan_cache: on/off 开启/关闭执行计划缓存功能;

Ø Cached_prepared_stmt_count: 监控已缓存的执行计划数。

3.Plan Cache性能测试

TPCC测试下数据明细:

Feature

BMSQLBase tpmC

BMSQLIncr. tpmC

Plan cache off

582967.16


Plan cache on

664607.06

81639.9

测试结果:性能提升14%

sysbench:

oltp_point_select 20%

通过对比测试,我们得知在开启Plan Cache功能的情况下,TPCC、sysbench point select场景分别有14%和20%的性能提升。

相比原生MySQL,在有大量相同查询语句的场景下,Plan Cache可以有效减少语句的优化时间,提升查询性能。目前,GaussDB(for MySQL) 执行计划缓存为会话级(会消耗额外的内存空间),支持场景为Prepare语句的单表查询、更新,未来会不断技术创新支持更多的场景,进行更多的改善和优化。

GaussDB(for MySQL)是华为云数据库重点打造的云原生数据库之一,除了Plan Cache功能,还基于存算分离架构,提供了跨AZ部署、极致扩展、一写多读,算子下推等云原生能力。如果您想要了解更多,可以回看华为云GaussDB在“华为云TechWave云原生2.0技术峰会”的精彩内容。

▼点击“阅读原文”,回看精彩内容

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部