redshift 优化官方文档

影响查询性能的因素

影响查询性能的因素有很多。数据、群集、数据库操作的以下方面都会影响查询过程的速度。

节点、处理器或切片的数量 - 一个计算节点分为多个切片。节点越多意味着处理器和切片越多，通过跨各个切片并发运行查询的多个部分，可加快查询的处理速度。但是，节点越多也意味着花费越高，因此，您需要为自己的系统找到成本和性能之间的适当平衡点。有关 Amazon Redshift 群集架构的更多信息，请参阅数据仓库系统架构。
节点类型 - Amazon Redshift 群集可以使用密集存储节点或密集计算节点。对于大量数据存储需求，推荐使用密集存储节点类型；密集计算节点类型是专为性能密集型工作负载而优化的。每个节点类型提供不同的大小和限制，以帮助您适当地扩展群集。节点大小决定群集中每个节点的存储容量、内存、CPU 和价格。有关节点类型的更多信息，请参阅 Amazon Redshift 定价。
数据分配 - Amazon Redshift 根据表的分配方式在计算节点上存储表数据。在执行查询时，查询优化程序根据执行联接和聚合的需要将数据重新分配到计算节点。为表选择适当的分配方式可在执行联接前将数据放置到所需位置，这有助于尽量减少重新分配步骤产生的影响。有关更多信息，请参阅 选择数据分配方式。
数据排序顺序 - Amazon Redshift 根据表的排序键将表数据按照排序顺序存储在磁盘中。查询优化程序和查询处理器利用数据放置位置的相关信息减少需要扫描的数据块数，从而提高查询速度。有关更多信息，请参阅 选择排序键。
数据集大小 - 群集中的数据量越大，则需要扫描和重新分配的行数也越多，这会降低查询性能。您可以定期对数据进行 Vacuum 和存档操作，并使用谓词来限制查询数据集，以减轻这一影响。
并发操作 - 同时运行多个操作会影响查询性能。每个操作都会占用可用查询队列中的一个或多个槽，并占用与这些槽关联的内存。如果其他操作正在运行，则可能没有充足的查询队列槽可用。在这种情况下，查询必须等待有槽回收后才能开始处理。有关创建和配置查询队列的更多信息，请参阅实施工作负载管理。
查询结构 - 查询的编写也会影响其性能。在满足需求的前提下，请尽量将查询编写为处理和返回尽量少的数据。有关更多信息，请参阅 查询设计最佳实践。
代码编译 - Amazon Redshift 为每个查询执行计划生成和编译代码。编译代码段存储在最近最少使用 (LRU) 缓存中，并在群集中的会话间共享。因此，同一查询的后续执行（即使在不同的会话中，以及在许多情况下，使用不同查询参数时）会运行得更快，因为它们可跳过初始生成和编译步骤。LRU 缓存在群集重启后依然保留，但可通过维护升级擦除。
编译代码执行更快，因为它消除了使用解释器的开销。但首次生成和编译代码总会产生一些开销。因此，首次运行查询时的性能可能会造成误导。运行一次性（临时）查询时，这一开销可能会特别明显。您应始终运行查询两次来确定其典型性能。
同样，在比较从不同客户端发送的同一查询的性能时要多加注意。执行引擎为 JDBC 连接协议和 ODBC 及 psql (libpq) 连接协议生成不同的代码。如果两个客户端使用不同的协议，则每个客户端都会产生首次生成编译代码的开销，即使是同一查询也不例外。不过，使用相同协议的其他客户端将因共享缓存代码而获益。使用 ODBC 的客户端和运行 psql (libpq) 的客户端可共享相同的编译代码。reference
影响查询性能的因素