【Azure Data Platform】Azure SQLDW 结果集缓存

本文属于【Azure Data Platform】系列。
接上文：【Azure Data Platform】Azure SQLDW与ADLS的整合
本文介绍SQL DW的结果集缓存（result set caching）

前言

随着数据量的不断增大，即使是SQL DW这种MPP架构，也很难通过单纯地提升DWU来维持性能。所以从SQL DW Gen2（现在用的都已经是Gen2了）开始，引入了一系列的提升性能的特性。比如列存储索引，结果集缓存等。

本文主要讲的是缓存，缓存的核心思想就是把常用的查询出来的结果集存储在内存，减少反复编译、检索等过程。

对于缓存，首先被想到的就是Redis，它确实是很厉害的工具，不过对于BI领域，这种无疑有一定的使用难度，毕竟BI关注的是数据的挖掘和使用，而不是这种性能提升，同时引入一个引擎也会带来相应的成本。

从2019年开始， Azure SQL DW引入了结果集缓存（result set caching）。它会将读取查询的结果存储在 Azure SQL DW 的控制节点中，并且将其返回给用户

优缺点

正如我一贯的说法，一个功能如果具有开关的选择，那证明它是有适用场景的。首先我们来说说“坏处”

缺点

1. 空间限制：1TB的大小限制。
2. 时间限制：48小时内没被用过，则失效。
3. 语法限制：不缓存中间结果。
4. 不生效的场景：对于不满足缓存的查询，会在本次执行后才存进去缓存，然后供下次使用，这样对于一些即席查询（ahoc query)并没有明显的效果。因为它们通常只查询一次。
5. 不支持某些特殊设置的查询：比如设置了行级安全性（Row level security, RLS）的查询。具体情况还有：不缓存哪些内容
6. 在ETL过程返回大量数据过程中，可能会因为占用带宽反而影响性能，所以这种情况下最好先关闭缓存功能。
7. 缓存的数据只对下一次查询语句一模一样（hash plan相同）的查询，才会有用，哪怕改动了一点点都不能利用到缓存功能。
8. 修改基础表的结构会使对应的缓存强制失效。

优点

之所以把优点放在缺点之后，是因为我更看中缺点的影响，如果影响太大，那么优点可能就没有价值了。

1. 这部分的查询不占用并发槽，所以不会影响现有的并发。
2. 缓存如果命中，则直接返回数据，减少了不必要的环节。这一部分会大大提高相应的查询速度，接下来会演示。

设置结果集缓存

要启用该功能，所需权限：master 库上具有dbmanager 数据库角色的成员。

先用下面语句检查是否已经弃用，如果启用，则返回 1，否则返回 0，我们用的测试库是已经启用了，所以这里先禁用：

禁用命令如下： 在master库运行alter database xxx set result_set_caching off， 再次检查，已经为0， 证明禁用。

然后我们用前面的测试环节做测试：【Azure Data Platform】Dedicated SQL Pool——导入性能测试（1）——传统insert。由于查询全表时间比较久，所以就只选了前10万行，因为创建了clustered index，所以已经有顺序，不会因为top导致每次运行的结果都不一样从而影响实验。

上图可以看到在特定环境下，运行了23~25秒，反复测试效果相差不大。并用下面语句检查它的情况：

监控功能的使用

可以通过 DMV 监控缓存使用情况，如果特定查询 ID 有缓存命中或未命中，您可以在查询请求步骤中查看到ReturnOperation的操作类型。也可以用官网中的方法查看：添加链接描述

 select * from sys.dm_pdw_request_steps where status='running'

然后我们重新开启缓存设置之后，跑第一次，因为第一次是不会有缓存，所以我们看到用了57秒。但是后面的查询就不一样了。

第二次查询，已经降到了12秒：

总结

从这个测试来看，缓存功能对需要反复查询的相同SQL 而言还是有相当不错的性能提升。不过正如前面所说，如果只是临时查询，则用处不大，反而占用了控制节点的缓存空间。

另外本人之前参与的SQL DW项目，因为主要是ETL过程的转换部分，对数据而言更多只是暂时存放并借用SQL DW的MPP架构提高处理速度，接着就会传输到下游系统，那么结果集缓存对这类操作的作用就不大了。毕竟很少有再次查询的机会。

因此，一个可选的功能，并不真的没有坏处，要着重检查它的适用场景是否合适。