Query Caching
当我们将同样的SQL语句执行两次时，第二次会执行的显示快一些。
例如执行两次上一节的join查询：
select
title.title,
title.language,
title_basics.primarytitle,
title_basics.startyear,
title_basics.genres
from imdb.title
join imdb.title_basics on title.titleid = title_basics.tconst
where title.language = 'en' limit 100;
第二次的时间会快很多：
2017年Redshift推出了一个新特性，会将第一次的执行结果缓存，在第二次执行同样的语句时，从缓存中读出结果并返回。这对于需要重复执行查询的情景，可以大大降低Redshift的查询压力，如BI报表工具。
它的原理和Redis差不多：
Redshift将查询结果保存在leader node的内存。如果想确认SQL查询结果有没有被缓存，可以从SVL_QLOG表里查询，source_query不为空的表示已缓存。这张表里还有一些元数据，如查询的起始时间、结束时间等信息：
另外，Query Caching在以下场景不会生效：
-
查询结果太大了，
leader node放不下 -
连接
Amazon Redshift Spectrum外部表时 -
当DML或DDL语句更新表时，Redshift会自动把缓存失效(很合理，防止读到脏数据)
Query Cache这个特性默认开启，如果想关掉，可以设置enable_result_cache_for_session = off
总结
- 必须全部满足才能命中缓存：
| 条件 | 说明 |
|---|---|
| SQL 完全相同 | 包括大小写、空格、注释 |
| 同一数据库 | 同一个 database |
| 底层数据未变 | 表没有被 INSERT/UPDATE/DELETE/TRUNCATE |
| 缓存未过期 | 默认缓存有效期内 |
| 同一用户权限 | 用户有权限访问相关表 |
- 缓存失效的条件：
| 触发条件 | 说明 |
|---|---|
| 数据变更 | INSERT/UPDATE/DELETE/COPY/TRUNCATE |
| DDL 操作 | ALTER TABLE/DROP TABLE |
| VACUUM | 表维护操作 |
| 集群重启 | 缓存在内存中，重启丢失 |
| 手动失效 | 无直接命令，但可通过修改数据触发 |