冗余数据JOIN导致的慢SQL优化一例

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS SQL Server,基础系列 2核4GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: CASE 一个这样的查询,每个表都只有几千条数据,但是查询非常慢,几十秒不出结果。 select distinct abc.pro_col1, abc.col3 from t0 p INNER JOIN t1 abc on p.id=abc.par_col2

CASE

一个这样的查询,每个表都只有几千条数据,但是查询非常慢,几十秒不出结果。

select  
distinct abc.pro_col1, abc.col3  
from  
t0 p  
INNER JOIN t1 abc 
  on p.id=abc.par_col2
inner join t2 s 
  on  s.col3=abc.col3  
inner join t3 po 
  on  po.id=s.col4 
where p.state=2 and po.state=3 
order by abc.pro_col1, abc.col3; 

优化方法

从语义来看,这条SQL是在经过几个JOIN后取其中一个表的两个字段的唯一值。

但是每一次关联,都可能产生冗余的值,所以导致了结果集越来越庞大。

修改建议,每一次JOIN都输出唯一值,减少冗余。

select 
distinct pro_col1, col3 from
(
select 
distinct t1.pro_col1, t1.col3, s.col4 from 
(
select 
distinct abc.pro_col1, abc.col3 from 
t1 abc INNER JOIN t0 p    
on (p.id = abc.par_col2 and p.state=2)
) t1
inner join t2 s 
on (s.col3 = t1.col3)
) t2
inner join t3 po   
on (po.id = t2.col4 and po.state=3)
order by t2.pro_col1, t2.col3  ;

修改后几十毫秒可以输出结果。

重现

postgres=# create table rt1(id int, info text);
CREATE TABLE
postgres=# create table rt2(id int, info text);
CREATE TABLE
postgres=# create table rt3(id int, info text);
CREATE TABLE
postgres=# create table rt4(id int, info text);
CREATE TABLE

postgres=# insert into rt1 select generate_series(1,1000),'test';
INSERT 0 1000
postgres=# insert into rt2 select 1,'test' from generate_series(1,1000);
INSERT 0 1000
postgres=# insert into rt3 select 1,'test' from generate_series(1,1000);
INSERT 0 1000
postgres=# insert into rt4 select 1,'test' from generate_series(1,1000);
INSERT 0 1000

以下查询,每次JOIN都产生大量的冗余数据,越到后面的JOIN,冗余越多,导致的查询非常漫长。

postgres=# explain select distinct rt1.id from rt1 join rt2 on rt1.id=rt2.id join rt3 on rt2.id=rt3.id join rt4 on rt3.id=rt4.id;
                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 HashAggregate  (cost=145.25..155.25 rows=1000 width=4)
   Group Key: rt1.id
   ->  Hash Join  (cost=113.00..142.75 rows=1000 width=4)
         Hash Cond: (rt4.id = rt1.id)
         ->  Seq Scan on rt4  (cost=0.00..16.00 rows=1000 width=4)
         ->  Hash  (cost=100.50..100.50 rows=1000 width=12)
               ->  Hash Join  (cost=70.75..100.50 rows=1000 width=12)
                     Hash Cond: (rt3.id = rt1.id)
                     ->  Seq Scan on rt3  (cost=0.00..16.00 rows=1000 width=4)
                     ->  Hash  (cost=58.25..58.25 rows=1000 width=8)
                           ->  Hash Join  (cost=28.50..58.25 rows=1000 width=8)
                                 Hash Cond: (rt2.id = rt1.id)
                                 ->  Seq Scan on rt2  (cost=0.00..16.00 rows=1000 width=4)
                                 ->  Hash  (cost=16.00..16.00 rows=1000 width=4)
                                       ->  Seq Scan on rt1  (cost=0.00..16.00 rows=1000 width=4)
(15 rows)

修改如下,可以很快的得到结果

postgres=# select distinct t2.id from 
(
select distinct t1.id from 
(select distinct rt1.id from rt1 join rt2 on rt1.id=rt2.id) t1
join 
rt3 on t1.id=rt3.id
) t2
join rt4 on t2.id=rt4.id
;
 id 
----
  1
(1 row)
Time: 2.052 ms

postgres=# explain select distinct t2.id from 
postgres-# (
postgres(# select distinct t1.id from 
postgres(# (select distinct rt1.id from rt1 join rt2 on rt1.id=rt2.id) t1
postgres(# join 
postgres(# rt3 on t1.id=rt3.id
postgres(# ) t2
postgres-# join rt4 on t2.id=rt4.id
postgres-# ;
                                                 QUERY PLAN                                                  
-------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=190.25..200.25 rows=1000 width=4)
   Group Key: rt1.id
   ->  Hash Join  (cost=158.00..187.75 rows=1000 width=4)
         Hash Cond: (rt4.id = rt1.id)
         ->  Seq Scan on rt4  (cost=0.00..16.00 rows=1000 width=4)
         ->  Hash  (cost=145.50..145.50 rows=1000 width=4)
               ->  HashAggregate  (cost=125.50..135.50 rows=1000 width=4)
                     Group Key: rt1.id
                     ->  Hash Join  (cost=93.25..123.00 rows=1000 width=4)
                           Hash Cond: (rt3.id = rt1.id)
                           ->  Seq Scan on rt3  (cost=0.00..16.00 rows=1000 width=4)
                           ->  Hash  (cost=80.75..80.75 rows=1000 width=4)
                                 ->  HashAggregate  (cost=60.75..70.75 rows=1000 width=4)
                                       Group Key: rt1.id
                                       ->  Hash Join  (cost=28.50..58.25 rows=1000 width=4)
                                             Hash Cond: (rt2.id = rt1.id)
                                             ->  Seq Scan on rt2  (cost=0.00..16.00 rows=1000 width=4)
                                             ->  Hash  (cost=16.00..16.00 rows=1000 width=4)
                                                   ->  Seq Scan on rt1  (cost=0.00..16.00 rows=1000 width=4)
(19 rows)

Time: 0.750 ms

小结

这种SQL,如果要改内核的话,可以对统计信息进行分析(每个字段都有n_distinct),并对其进行query rewrite,得到同样的结果。

postgres=# \d pg_stats
          View "pg_catalog.pg_stats"
         Column         |   Type   | Modifiers 
------------------------+----------+-----------
 schemaname             | name     | 
 tablename              | name     | 
 attname                | name     | 
 inherited              | boolean  | 
 null_frac              | real     | 
 avg_width              | integer  | 
 n_distinct             | real     | 
 most_common_vals       | anyarray | 
 most_common_freqs      | real[]   | 
 histogram_bounds       | anyarray | 
 correlation            | real     | 
 most_common_elems      | anyarray | 
 most_common_elem_freqs | real[]   | 
 elem_count_histogram   | real[]   | 

祝大家玩得开心,欢迎随时来 阿里云促膝长谈业务需求 ,恭候光临

阿里云的小伙伴们加油,努力 做好内核与服务,打造最贴地气的云数据库

目录
相关文章
|
27天前
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
14天前
|
SQL 缓存 数据库
SQL慢查询优化策略
在数据库管理和应用开发中,SQL查询的性能优化至关重要。慢查询优化不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将详细介绍针对SQL慢查询的优化策略。
|
14天前
|
SQL 存储 BI
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
gbase 8a 数据库 SQL合并类优化——不同数据统计周期合并为一条SQL语句
|
14天前
|
SQL 数据库
gbase 8a 数据库 SQL优化案例-关联顺序优化
gbase 8a 数据库 SQL优化案例-关联顺序优化
|
21天前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
35 3
|
1月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
99 10
|
1月前
|
SQL 存储 缓存
SQL Server 数据太多如何优化
11种优化方案供你参考,优化 SQL Server 数据库性能得从多个方面着手,包括硬件配置、数据库结构、查询优化、索引管理、分区分表、并行处理等。通过合理的索引、查询优化、数据分区等技术,可以在数据量增大时保持较好的性能。同时,定期进行数据库维护和清理,保证数据库高效运行。
|
1月前
|
SQL
SQL JOIN
【11月更文挑战第06天】
44 4
|
2月前
|
SQL 关系型数据库 MySQL
图解 SQL 里的各种 JOIN
用文氏图表示 SQL 里的各种 JOIN,一下子就理解了。
43 2
|
21天前
|
SQL 缓存 监控
SQL性能提升指南:五大优化策略与十个实战案例
在数据库性能优化的世界里,SQL优化是提升查询效率的关键。一个高效的SQL查询可以显著减少数据库的负载,提高应用响应速度,甚至影响整个系统的稳定性和扩展性。本文将介绍SQL优化的五大步骤,并结合十个实战案例,为你提供一份详尽的性能提升指南。
42 0