一起来读Greenplum/Deepgreen执行计划

简介: 日常SQL优化过程中,最好用的手段就是通过执行计划。在Greenplum和Deepgreen中,运行 EXPLAIN 后产生的执行计划呈树状,这棵树的每一个分叉,都代表了一个单独的数据库操作,例如:表扫描、表连接、聚合、排序。

日常SQL优化过程中,最好用的手段就是通过执行计划。在Greenplum和Deepgreen中,运行 EXPLAIN 后产生的执行计划呈树状,这棵树的每一个分叉,都代表了一个单独的数据库操作,例如:表扫描、表连接、聚合、排序。

由于返回数据行数是从下向上传递的,所以我们在分析执行计划时,也应该自下而上。通常来说,最底下的是表扫描操作(索引、位图索引扫描)。如果查询中涉及到连接、聚合、排序操作,那么表扫描动作的上层就会有对应的这些操作。通常最顶上的部分是节点间数据移动(重分布、广播、聚集操作),在查询过程中,这些操作会涉及到在节点间移动数据。

EXPLAIN 执行计划中,每一个单独的步骤都会呈现在单独一行里,带有对应的动作类型及查询数据所耗费的时间(查询首行所用时间..查询全部所用时间):

1.cost

Cost以磁盘页读取为测量单位,1.0等同于一个顺序的磁盘页读取。第一个预估时间是起始消耗,即查询首行所消耗的时间,第二个预估值是总消耗,即查询全部行所用的时间。

2.rows

rows指的是执行计划某部分返回的总行数。这个数量通常少于实际的返回行数,反应的只是一个预估的数量。最顶层的返回的预估数量最接近实际查询、修改或删除影响的行数。

3.width

操作返回的所有数据所占用的字节数。

很重要的一点是,上层节点所花费的时间包括所以子节点占用时间,计划最顶层包含总执行花费的预估,这也是我们追求优化的部分。另外执行计划的消耗只与执行计划本身关心的步骤有关,与查询结果传输到客户端的消耗时间等因素无关。

如果某个查询的性能特别低,那么我们可以通过查看执行计划来定位问题原因。下面是一些小技巧

1.查询计划中是否有操作耗时特别的长?

当我们分析查询计划时,是否有一个异常操作消耗了大部分的查询时间?比如,在执行索引扫描时,时间比预期的要长很多,这时候我们基本可以判断此索引可能已经超期了,需要重建。

2.查询计划预估的时间和真实的时间接近吗?

我们通过运行 EXPLAIN ANALYZE ,查看执行计划预估的返回行数与实际返回的行数是否接近,如果出入很大,说明统计信息是有问题的,我们需要对相关表/列收集更多的统计信息。

3.选择语句中的限定条件是否生效更早?

在执行计划中,选择性限定条件应该更早的应用,目的是让更少的数据返回到上层操作中。如果查询在选择性限定条件应用后表现并不好,返回的消耗依然很大,我们可以收集相关列的统计信息再看看是否会提高性能;另外,还可以通过调整SQL语句中不合理的 WHERE 条件来提高性能。

4.查询计划是否选择了最佳的JOIN顺序?

当我们的查询里面有很多连接操作(JOIN)时,要确保执行计划选择了一个最优连接顺序。拥有大量返回数据的连接应该尽早完成,以保证我们为上层操作返回更少的行。如果执行计划没有选择最佳的连接顺序,我们可以设置参数 join_collapse_limit=1 ,然后在SQL语句中使用明确的JOIN语法强迫执行计划按照特定的执行顺序执行。另外,我们可以收集相关列的统计信息再看看是否会提高性能。

5.查询计划是否有选择性的扫描分区表?

如果我们使用查询中涉及到了分区表数据查询,那么查询计划是否直接定位到扫描满足条件的分区,而不是扫描整张表。

6.查询计划是否适当的选择Hash Aggregate和Hash Join操作?

Hash操作比其他类型的聚合或者连接操作要快很多,行数据的比较和分类操作是在内存中进行,而不是通过读写磁盘完成。为了能够使用Hash操作,我们必须保证有足够的 work memory 可以容纳查询计划返回的行数据,所以我们可以通过尝试增加work memory来提高查询性能。通过运行EXPLAIN ANALYZE命令,这样可以看出哪些计划会有数据使用到磁盘,需要多少额外的work memory等,为work memory的调整提供参考。例如:

Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).
Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen workfile I/O affecting 2 workers.

Ends~

目录
相关文章
|
SQL 弹性计算 关系型数据库
HTAP数据库 PostgreSQL 场景与性能测试之 3.1 - (OLAP) 大表JOIN统计查询-10亿 join 1亿 agg
标签 PostgreSQL , HTAP , OLTP , OLAP , 场景与性能测试 背景 PostgreSQL是一个历史悠久的数据库,历史可以追溯到1973年,最早由2014计算机图灵奖得主,关系数据库的鼻祖Michael_Stonebraker 操刀设计,PostgreSQL具备与Oracle类似的功能、性能、架构以及稳定性。 PostgreSQL社区的贡献者众多
2201 0
|
流计算
Flink自定义source、自定义sink
Flink自定义source、自定义sink
338 0
|
机器学习/深度学习 算法 计算机视觉
YOLOv5改进 | 损失函数篇 | 最新ShapeIoU、InnerShapeIoU损失助力细节涨点
YOLOv5改进 | 损失函数篇 | 最新ShapeIoU、InnerShapeIoU损失助力细节涨点
564 1
|
1月前
|
SQL 关系型数据库 Apache
从 Flink 到 Doris 的实时数据写入实践 —— 基于 Flink CDC 构建更实时高效的数据集成链路
本文将深入解析 Flink-Doris-Connector 三大典型场景中的设计与实现,并结合 Flink CDC 详细介绍了整库同步的解决方案,助力构建更加高效、稳定的实时数据处理体系。
902 0
从 Flink 到 Doris 的实时数据写入实践 —— 基于 Flink CDC 构建更实时高效的数据集成链路
|
存储 缓存 NoSQL
Redis使用|缓存穿透,雪崩,击穿以及解决方案分析
前言作为一种非关系型数据库,redis也总是免不了有各种各样的问题,这篇文章主要是针对其中三个问题进行讲解:缓存穿透、缓存击穿和缓存雪崩,并给出一些解决方案。一. 什么是 缓存穿透缓存穿...
645 0
|
9月前
|
Oracle 安全 关系型数据库
【赵渝强老师】PostgreSQL的参数文件
PostgreSQL数据库的四个主要参数文件包括:`postgresql.conf`(主要配置文件)、`pg_hba.conf`(访问控制文件)、`pg_ident.conf`(用户映射文件)和`postgresql.auto.conf`(自动保存修改后的参数)。视频讲解和详细说明帮助理解各文件的作用。
288 19
|
11月前
|
存储 缓存 负载均衡
使用一致性哈希让数据均匀分布
使用一致性哈希让数据均匀分布
205 2
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
296 6
|
安全 网络安全 数据安全/隐私保护
|
存储 分布式计算 负载均衡
分布式(计算机算法)
分布式(计算机算法)