本文属于【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 的控制节点中，并且将其返回给用户
优缺点
正如我一贯的说法，一个功能如果具有开关的选择，那证明它是有适用场景的。首先我们来说说“坏处”
缺点
- 空间限制：1TB的大小限制。
- 时间限制：48小时内没被用过，则失效。
- 语法限制：不缓存中间结果。
- 不生效的场景：对于不满足缓存的查询，会在本次执行后才存进去缓存，然后供下次使用，这样对于一些即席查询（ahoc query)并没有明显的效果。因为它们通常只查询一次。
- 不支持某些特殊设置的查询：比如设置了行级安全性（Row level security, RLS）的查询。具体情况还有：不缓存哪些内容
- 在ETL过程返回大量数据过程中，可能会因为占用带宽反而影响性能，所以这种情况下最好先关闭缓存功能。
- 缓存的数据只对下一次查询语句一模一样（hash plan相同）的查询，才会有用，哪怕改动了一点点都不能利用到缓存功能。
- 修改基础表的结构会使对应的缓存强制失效。
优点
之所以把优点放在缺点之后，是因为我更看中缺点的影响，如果影响太大，那么优点可能就没有价值了。
- 这部分的查询不占用并发槽，所以不会影响现有的并发。
- 缓存如果命中，则直接返回数据，减少了不必要的环节。这一部分会大大提高相应的查询速度，接下来会演示。
设置结果集缓存
要启用该功能，所需权限：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架构提高处理速度，接着就会传输到下游系统，那么结果集缓存对这类操作的作用就不大了。毕竟很少有再次查询的机会。
因此，一个可选的功能，并不真的没有坏处，要着重检查它的适用场景是否合适。