AWS Redshift 查询的执行计划（1）

本文主要是介绍AWS Redshift 查询的执行计划（1），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

首先，需要了解一条查询在 Redshift 中所执行的步骤。

1. 领导节点接收查询并解析 SQL。、

2. 分析程序生成初步查询树，后者是原始查询的逻辑表示。然后，Amazon Redshift 将该查询树输入到查询优化程序中。

3. 优化器会评估，如有必要，请重新写入查询以最大程度提高效率。这个过程有时会导致创建多个相关查询来替换单个。

4. 优化程序生成查询计划（或若干以上步骤，如果上一步导致执行多个查询），则执行最佳性能。查询计划指定执行选项，例如联接类型、联合订单、聚合选项和数据分发要求。

5. 执行引擎将查询计划转换为 steps， segments 和 streams:
   步骤
   每个步骤都是在查询执行期间需要的单独操作。可以组合步骤，以允许计算节点执行查询、加入或其他数据库操作。
   段
   可通过单个过程完成的几个步骤的组合，也可以通过计算节点层执行最小的编译单元。A slice 是并行处理的单位 Amazon Redshift. 并行运行的流中的段。
   流
   在可用计算节点切片上划分的分段集合。
   执行引擎基于步骤、段和流生成编译后的代码。编译代码的执行速度比解释代码更快，而且计算容量更少。此编译代码然后播放到计算节点。

6. 计算节点层以并行方式执行查询段。在该流程中，Amazon Redshift 利用优化的网络通信、内存和磁盘管理，将中间结果从一个查询计划步骤传递到下一个，这也有助于加快查询的执行。

下面看一下 AWS Redshift 文档中的流程图。

---

我们可以通过 Explain 查看查询的执行计划. 这部分内容与PG类似。
Query Plan 中的信息：

• 成本 - 对比计划内运行的相对值。
• 行数 - 要返回的预估行数。
• Width - 平均行的估计宽度（字节）。

成本代表执行每一个步骤时，所花费的成本。那么数值时如何算出来的呢？
处理每行记录花费的代价，默认为 0.01
每次索引查询进入索引处理的代价，默认为 0.005
设置计划程序是对查询期间执行的每个运算符或函数的处理成本的估计。 默认值为0.0025。

testdb=# explain select * from test_even_01
;QUERY PLAN
------------------------------------------------------------------------------XN Seq Scan on test_even_01  (cost=0.00..0.10 rows=10 width=172)----- Tables missing statistics: test_even_01 ---------- Update statistics by running the ANALYZE command on these tables -----
(3 rows)testdb=# analyze test_even_01;
ANALYZE
testdb=# explain select * from test_even_01;QUERY PLAN
-----------------------------------------------------------------XN Seq Scan on test_even_01  (cost=0.00..0.10 rows=10 width=11)
(1 row)

---

Explain 中常见的操作, 很多内容同 PG 类似。

1. Sequential scan operator

2. Join operators
   (1) Nested Loop
   (2) Hash Join and Hash
   (3) Merge Join

3. Aggregate operators
   (1) Aggregate
   (2) HashAggregate
   (3) GroupAggregate

4. Sort operators
   (1) Sort
   (2) Merge

5. UNION, INTERSECT, and EXCEPT operators
   (1) Subquery
   (2) Hash Intersect Distinct
   (3) SetOp Except

6. Other operators
   (1) Unique
   (2) Limit
   (3) Window
   (4) Result
   (5) Subplan
   (6) Network
   (7) Materialize

---

DS_BCAST_INNER

• 整个内部表被广播到所有节点

DS_DIST_ALL_NONE
不需要重新分配，因为表的分配方式为 ALL，已经存在在每个节点。

DS_DIST_NONE
没有表被重新分配，在没有在节点之间移动数据的情况下联接了相应的片。

DS_DIST_INNER
内部表被重新分配。

DS_DIST_OUTER
外部表被重新分配。

DS_DIST_ALL_INNER
由于外部表使用分配方式为ALL， 所以整个内部表都重新分配给单个片。

DS_DIST_BOTH
两个表都被重新分配

---

影响查询性能的因素

1. Number of nodes, processors, or slices
2. Node types
3. Data distribution
4. Data sort order
5. Dataset size
6. Concurrent operations
7. Query structure
8. Code compilation

这篇关于AWS Redshift 查询的执行计划（1）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---