选择Plan Cache功能，让您远离SQL语句执行慢烦恼
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技术峰会”的精彩内容。
▼点击“阅读原文”，回看精彩内容