执行计划缓存，Prepared Statement性能跃升的秘密
摘要：一起看一下GaussDB(for MySQL)是如何对执行计划进行缓存并加速Prepared Statement性能的。
本文分享自华为云社区《执行计划缓存，Prepared Statement性能跃升的秘密》，作者： GaussDB 数据库。
引言
在数据库系统中，SQL（Structured Query Language）语句输入到系统后，一般要经历：词法语法解析(parse)、重写（resolve）、优化（optimize）、执行(execute)的过程。词法语法分析，重写和优化，这三个阶段会生成SQL语句的执行计划 (plan)。当SQL语句存在多种执行计划的时候，优化器会从这许多的执行计划中挑选出一个它认为最优的（通常是占用系统资源最少的，包括CPU以及IO等）作为最终的执行计划供执行器执行。生成执行计划的过程会消耗较多的时间，特别是存在许多可选的执行计划时。
图1：SQL语句执行
Prepared Statement是将SQL语句中的值用占位符替代，可以视为将SQL语句模板化或者说参数化。当执行PREPARE语句时，传统MySQL将对指定的语句进行词法语法解析和重写，如上图①②。该阶段称为预编译阶段。Prepared Statement的优势在于一次编译、多次运行，省去了预编译阶段需要的时间。随后发出EXECUTE命令时，MySQL将对编译阶段生成的结构执行优化，即上图的③，生成对应的执行计划并执行，把输出结果返回到客户端。例如：
PREPARE stmt FROM ‘SELECT * FROM t WHERE t.a = ?’; SET @var = 2; EXECUTE stmt USING @var;
传统MySQL的Prepared Statement只会节省SQL语句的解析及重写过程需要的时间，但是对于一条SQL语句，如文章开头所述，优化SQL语句并生成执行计划需要耗费大量的资源以及时间。如果能将该Prepared Statement语句对应的最终执行计划进行缓存，当执行EXECUTE语句的时候，就可以直接使用已缓存的执行计划，从而就可以跳过SQL语句生成执行计划的整个过程，进而可以提高语句的执行性能。为此，GaussDB(for MySQL) 提供了Prepared Statement执行计划缓存特性。
接下来一起看一下GaussDB(for MySQL)是如何对执行计划进行缓存并加速Prepared Statement性能的。
执行计划缓存工作原理
GaussDB(for MySQL)对Prepared Statement执行计划进行缓存的基本原理和流程如下图所示：
- 响应EXECUTE，执行查询。
- 通过is_plan_cached过程来查看当前Query的执行计划是否已经被缓存。
- 如果已经被缓存，优化器将对当前的Query缓存的执行计划进行初始化，根据执行计划的上下文还原执行计划，然后利用还原的执行计划继续执行。
- 如果没有被缓存，在执行完Query优化生成执行计划之后，通过is_query_cachable过程验证当前执行计划是否可以被缓存。
- 如果满足缓存条件，执行计划将会被缓存（调用cache_JOIN_plan），以便以后的EXECUTE语句可以利用该缓存的计划进行执行。
- 如果不能缓存，通过传统的MySQL执行流程（优化，生成执行计划然后执行）执行EXECUTE语句。
执行计划缓存管理
- 执行计划缓存功能开关
GaussDB(for MySQL)引入了一个新的系统参数rds_plan_cache来开关Prepared Statement执行计划缓存功能。
rds_plan_cache：该参数可以设置为ON/OFF。分别代表开启和关闭执行计划缓存。该参数是Session/Global级别的参数。
- 查看执行计划缓存情况
GaussDB(for MySQL)提供了两个状态变量供用户查看或者验证Prepared Statement执行计划是否被缓存，以及在执行时是否命中了缓存的执行计划。
- cached_plan_count：显示有多少个Prepared Statement缓存了执行计划。这是一个Global级别的状态变量。
- cached_plan_hits：显示EXECUTE执行过程中命中了缓存的执行计划的次数。这是一个Session/Global状态。
下面举例来看一下Prepared Statement是如何利用了执行计划缓存特性的：
SET @a = 'two'; SET @b = 3; PREPARE stmt FROM "SELECT * FROM t1 WHERE b = ? AND c = ?"; EXECUTE stmt USING @a,@b;
执行结果如下：
a b c 6 two 3
再次执行Prepared Statement：
EXECUTE stmt USING @a,@b; a b c 6 two 3
第三次执行Prepared Statement：
execute stmt using @a,@b; a b c 6 two 3
通过cached_plan_count和cached_plan_hits查看stmt执行计划是否被缓存，以及在执行时是否命中了缓存的执行计划。
SHOW SESSION STATUS LIKE "cached_plan%";
显示结果如下：
Variable_name Value Cached_plan_count 1 Cached_plan_hits 2
从显示结果可以看出，第一次执行EXECUTE语句的时候，Prepared Statement对执行计划进行了缓存，即可以看到Cached_plan_count为1； 之后执行两次EXECUTE语句，都命中了执行计划缓存，所以可以看到Cached_plan_hits变成了2。
缓存的执行计划如何失效
为了保持当前缓存的执行计划是尽可能最优的，GaussDB(for MySQL)定义了如下规则来对当前缓存的计划进行失效，并重新生成执行计划：
- 执行计划相关表的记录数更改超过总记录数的20%。
这意味着当前表的记录数如果插入/删除超过20%的记录，当前缓存计划将失效并在优化后重新缓存。注：记录数是根据统计数据估计的。所以最好先对表进行Analyze。 - 表定义进行了更改。
例如，执行计划相关表上进行的DDL将导致缓存计划无效，并在优化后重新缓存。 - 如果系统变量Optimizer_switch中影响执行计划生成的选项值进行了更改，则缓存的计划将失效，并在优化后重新缓存。
- 系统字符集发生变化，与缓存的计划不同时，将导致缓存计划失效，并在优化后重新缓存。
执行计划缓存功能当前的一些限制
GaussDB(for MySQL)的Prepared Statement的目的是节约查询的优化时间。对于通过并行查询优化的大查询，也就是数据量相对庞大的查询，这些查询大部分的执行时间是集中在执行计划的执行阶段。对于该类型的查询，优化时间相比执行时间而言可以忽略不计，所以GaussDB(for MySQL)没有对并行查询计划进行缓存。另外，GaussDB(for MySQL)对于Prepared statement 缓存执行计划的能力还在逐步增强中，比如当前只支持单表的SELECT查询语句，暂时还不支持UNION操作。
执行计划缓存性能测试结果
对于使用执行计划缓存和不使用执行计划缓存的场景，基于Sysbench测试集进行了性能测试对比，从测试结果可以看出，在启用执行计划缓存后，各类业务性能均有提升。注意：这些测试只代表相对数字，并不代表实际性能。
测试环境配置如下：
数据集 : 8 个表，每个表1000万行
测试服务器：Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz 2 physical cores 56 processors 460G memory
总结
GaussDB(for MySQL)通过缓存执行计划，可以提升Prepared Statement的性能。特别是针对Range Scan的测试集，性能提升可达2倍左右。未来我们会支持越来越多的查询场景，性能加速值得期待。