HANA 性能分析（三）SQL plan Cache 分析实例

最近遇到了SQL plan Cache 相关的问题，整理分析思路与使用工具如下：

在HANA Minicheck中，发现SQL cache相关的问题项：

问题描述：从Minicheck报告中可以看到，retention time（一条SQL缓存在内存里保留的时间）远远小于标准值，同时有大量的缓存失效(eviction)。

问题分析：首先要弄清楚缓存失效的原因，使用
SELECT LAST_INVALIDATION_REASON ,COUNT(*) FROM SYS.M_SQL_PLAN_STATISTICS GROUP BY LAST_INVALIDATION_REASON;

可以看到，缓存失效的绝大多数原因都是cache full，也就是说可能是缓存设的太小了。

继续分析，使用HANA_Memory_SQLCache_TopConsumers，这个SQL在上一节中没有提到，正好利用这个实例介绍：

字段名还是比较易读的，排第一的SQL在缓存里有5721条，平均每个787k，共4.29G，占据了72%的缓存。排第二的SQL在缓存里有29165条，平均每个36k，共1.01G，占据17%的缓存。至此，成功定位问题语句。

根据得到的语句哈希值，使用HANA_SQL_StatementHash_SQLText查找语句，可以看到第一种是一类查询语句，第二种是一类插入语句，经过观察，这些语句都有相同的问题：条件都直接写进了语句里，没有使用预编译的形式（binding variables）

这样带来的问题体现在两方面：

1. 浪费缓存空间：明明是同样的查询语句，仅仅因为查询条件的取值不同，就会产生多条缓存，浪费了大量缓存空间
2. 浪费CPU资源：除了浪费缓存，数据库还会额外花费CPU对相同的语句进行预编译，严重影响效率。当不使用预编译时，每次执行语句都需要额外的准备时间。而当使用预编译时，如图所示：
   
   可以看到，当使用预编译时，执行次数比准备次数多得多。而且通过后两列也可以看到，准备的时间也是比执行的时间长很多的，所以如果不使用预编译，将相当大程度上影响系统的响应时间，越常用的语句影响自然也就越大。