PostgreSQL UPDATE 中包含子查询的性能优化

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介:
一位网友使用update t1 set info=(select info from t2 where t1.id=t2.id) where t1.id<9999;这种查询时,发现性能很低。
而单独执行时很快的。
原因分析:
postgres=# create table t1(id int,info text);
CREATE TABLE
postgres=# create table t2(id int,info text);
CREATE TABLE

postgres=# insert into t1 select generate_series(1,10000) ;
INSERT 0 10000
postgres=# insert into t2 select generate_series(1,1000) ;
INSERT 0 1000
这个SubPlan循环了9998次,慢就慢在这里,虽然单次subquery只需要0.132毫秒,乘以9998后就是1300多毫秒了。
postgres=# explain (analyze,verbose,timing,buffers) update t1 set info=(select info from t2 where t1.id=t2.id) where t1.id<9999;
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Update on public.t1  (cost=0.00..145134.50 rows=9999 width=10) (actual time=1368.041..1368.041 rows=0 loops=1)
   Buffers: shared hit=39870
   ->  Seq Scan on public.t1  (cost=0.00..145134.50 rows=9999 width=10) (actual time=0.218..1337.192 rows=9998 loops=1)
         Output: t1.id, (SubPlan 1), t1.ctid
         Filter: (t1.id < 9999)
         Rows Removed by Filter: 2
         Buffers: shared hit=20020
         SubPlan 1
           ->  Seq Scan on public.t2  (cost=0.00..14.50 rows=1 width=32) (actual time=0.127..0.132 rows=0 loops=9998)
                 Output: t2.info
                 Filter: (t1.id = t2.id)
                 Rows Removed by Filter: 1000
                 Buffers: shared hit=19996
 Planning time: 0.095 ms
 Execution time: 1368.077 ms
(15 rows)
将SQL修改为update ... set ... from ... where ...;
LOOP消失,性能立马提升
postgres=# explain (analyze,verbose,timing,buffers) update t1 set info=t2.info from t2 where t1.id=t2.id and t1.id<9999;
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Update on public.t1  (cost=24.50..221.00 rows=1000 width=48) (actual time=8.103..8.103 rows=0 loops=1)
   Buffers: shared hit=1940
   ->  Hash Join  (cost=24.50..221.00 rows=1000 width=48) (actual time=0.569..5.295 rows=1000 loops=1)
         Output: t1.id, t2.info, t1.ctid, t2.ctid
         Hash Cond: (t1.id = t2.id)
         Buffers: shared hit=26
         ->  Seq Scan on public.t1  (cost=0.00..149.00 rows=9999 width=10) (actual time=0.038..2.600 rows=9998 loops=1)
               Output: t1.id, t1.ctid
               Filter: (t1.id < 9999)
               Rows Removed by Filter: 2
               Buffers: shared hit=24
         ->  Hash  (cost=12.00..12.00 rows=1000 width=42) (actual time=0.518..0.518 rows=1000 loops=1)
               Output: t2.info, t2.ctid, t2.id
               Buckets: 1024  Batches: 1  Memory Usage: 51kB
               Buffers: shared hit=2
               ->  Seq Scan on public.t2  (cost=0.00..12.00 rows=1000 width=42) (actual time=0.025..0.240 rows=1000 loops=1)
                     Output: t2.info, t2.ctid, t2.id
                     Buffers: shared hit=2
 Planning time: 0.237 ms
 Execution time: 8.156 ms
(20 rows)

对于多个子查询的修改例子:
update u_md_rs.s_tmp_zb010s_top4_show t1
     set sal_store_num_this = (select sal_store_num_this from u_md_rs.s_tmp_zb010s_top4_show t2
                                where t1.region_no = t2.region_no
                                  and t1.region_name = t2.region_name
                                  and t2.product_code='total_sal_num'),
         inv_store_num = (select inv_store_num from u_md_rs.s_tmp_zb010s_top4_show t2
                           where t1.region_no = t2.region_no
                             and t1.region_name = t2.region_name
                             and t2.product_code='total_inv_num')
   where t1.merge_flag='top'; 
改为
update u_md_rs.s_tmp_zb010s_top4_show t1 set 
sal_store_num_this = case when t2.product_code='total_sal_num' then t2.sal_store_num_this else t1.sal_store_num_this end ,
inv_store_num = case when t2.product_code='total_inv_num' then t2.inv_store_num else t1.inv_store_num end 
from s_tmp_zb010s_top4_show t2 
where t1.region_no = t2.region_no 
and t1.region_name = t2.region_name 
and t1.merge_flag='top' 
and (t2.product_code='total_sal_num' or t2.product_code='total_inv_num');
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
6月前
|
SQL Oracle 关系型数据库
实时计算 Flink版操作报错之往GREENPLUM 6 写数据,用postgresql-42.2.9.jar 报 ON CONFLICT (uuid) DO UPDATE SET 语法有问题。怎么解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
1月前
|
SQL 关系型数据库 数据库
postgresql报:ERROR: column “i“ of relation “test“ does not exist LINE 1: UPDATE怎么解决?
解决“ERROR: column "i" of relation "test" does not exist”错误的关键在于核实列名的准确性,修正更新语句,确保列名的引用正确无误,并考虑到任何可能影响列名引用的表别名、大小写、特殊字符或动态SQL生成等因素。通过上述步骤,你应该能有效定位并解决问题,保证SQL语句的正确执行。
331 0
|
关系型数据库 PostgreSQL
postgresql通过select结果进行update
postgresql通过select结果进行update
115 0
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
839 4
|
关系型数据库 PostgreSQL
PostgreSQL 性能优化: 等待事件
等待事件是 PostgreSQL 的重要优化工具。当您能查明会话为什么在等待资源以及会话在做什么时,您就能更好地减少瓶颈。您可以使用本节中的信息来查找可能的原因和纠正措施。
274 0
|
关系型数据库 PostgreSQL
PostgreSQL 性能优化: EXPLAIN 使用教程
PostgreSQL为每个收到的查询产生一个查询计划。选择正确的计划来匹配查询结构和数据的属性对于好的性能来说绝对是最关键的,因此系统包含了一个复杂的规划器来尝试选择好的计划。你可以使用EXPLAIN命令察看规划器为任何查询生成的查询计划。
236 0
|
关系型数据库 PostgreSQL 索引
PostgreSQL 性能优化: 执行计划
PostgreSQL为每个收到的查询产生一个查询计划。查询计划的结构是一个计划结点的树。最底层的结点是扫描结点:它们从表中返回未经处理的行。不同的表访问模式有不同的扫描结点类型:顺序扫描、索引扫描、位图索引扫描。也还有不是表的行来源,例如VALUES子句和FROM中返回集合的函数,它们有自己的结点类型。如果查询需要连接、聚集、排序、或者在未经处理的行上的其它操作,那么就会在扫描结点之上有其它额外的结点来执行这些操作。并且,做这些操作通常都有多种方法,因此在这些位置也有可能出现不同的结点类型。
121 0
|
存储 监控 AliSQL
RDS AliSQL 面向 Binlog 的性能优化大揭密(上)—— 极致 IO 优化
RDS MySQL使用AliSQL内核,为用户提供了MySQL所有的功能,同时提供了企业级的安全、备份、恢复、监控、性能优化、只读实例、Serverless等高级特性
3409 3
RDS AliSQL 面向 Binlog 的性能优化大揭密(上)—— 极致 IO 优化
|
AliSQL 关系型数据库 MySQL
RDS AliSQL 面向 Binlog 的性能优化大揭密(下)——强效瓶颈消除
本篇将继续揭秘AliSQL在binlog高并发性能上做的企业级优化。
RDS AliSQL 面向 Binlog 的性能优化大揭密(下)——强效瓶颈消除
|
关系型数据库 数据库 数据安全/隐私保护
RDS 5.6 执行update更新报ERROR 1142 (42000)
RDS 5.6 执行update更新报ERROR 1142 (42000)
RDS 5.6 执行update更新报ERROR 1142 (42000)

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版
  • 下一篇
    无影云桌面