SQL优化一例:查询条件内移,减少HASH JOIN代价

简介:

 
 
  1. 以下语句完全正确,但COST较高,原因是因为AEH、AEC、AC、ACSN几张表都有数百万条记录, 
  2. 由于采用了HASH连接,尝试采用优化索引等多种方式,但是由于记录过多,表的查询条件相对较少, 
  3. COST下降幅度始终很有限,COST提高到1000出头已经很尽力了。 
  4. Select Count(Tmp.Id) 
  5. From (Select Rownum As Id, t.Entry_Id, t.Container_Id, Con.Container_Num 
  6.              From AEC t 
  7.              Inner Join AEH Head On t.Entry_Id = Head.Entry_Id 
  8.              Inner Join AC Con On t.Container_Id = Con.Id And Head.Deleted_Flag = '0' And Con.Deleted_Flag = '0') Tmp 
  9.        Inner Join ACSN Constatus On Tmp.Container_Id = Constatus.Container_Id And 
  10.        Constatus.Px_Operation_Status <> '0'  
  11.        And Tmp.Entry_Id = :B2  
  12.        And Tmp.Container_Num = :B1 
  13.  
  14. SELECT STATEMENT, GOAL = ALL_ROWS                                Cost=3519   Cardinality=1       Bytes=62 
  15.  SORT AGGREGATE                                                 Cardinality=1       Bytes=62 
  16.   MERGE JOIN                                             Cost=3519   Cardinality=51      Bytes=3162 
  17.    TABLE ACCESS BY INDEX ROWID      Object owner=TEST   Object name=ACSN        Cost=774    Cardinality=49      Bytes=343 
  18.     INDEX FULL SCAN          Object owner=TEST   Object name=FK_A_C_C_S_P    Cost=6      Cardinality=1849     
  19.    SORT JOIN                                             Cost=2745   Cardinality=1470    Bytes=80850 
  20.     VIEW                 Object owner=TEST                    Cost=2744   Cardinality=1470    Bytes=80850 
  21.      COUNT                   
  22.       HASH JOIN                                          Cost=2744   Cardinality=1470    Bytes=94080 
  23.        NESTED LOOPS                                      Cost=1494   Cardinality=1470    Bytes=64680 
  24.         INDEX FAST FULL SCAN        Object owner=TEST   Object name=IDX_A_E_C   Cost=5      Cardinality=1470    Bytes=33810 
  25.         TABLE ACCESS BY INDEX ROWID Object owner=TEST   Object name=AEH         Cost=2      Cardinality=1       Bytes=21 
  26.          INDEX UNIQUE SCAN       Object owner=TEST   Object name=PK_AEH      Cost=1      Cardinality=1    
  27.        TABLE ACCESS FULL         Object owner=TEST   Object name=A_CO        Cost=1220   Cardinality=1005299 Bytes=20105980 
  28.  
  29.  
  30. 但再细看可以发现有如下苗头: 
  31.        And Tmp.Entry_Id = :B2  
  32.        And Tmp.Container_Num = :B1 
  33. 两个条件是等AEC、AEH、AC三个表HASH连接后才做的过滤,为啥不在连接前就对表做过滤, 
  34. 再一查在AEH表中有Entry_Id字段,而Container_Num是AC中的一个字段,于是把这两个 
  35. 条件从对TMP的外层过滤移入到AEH、AC内层过滤中,语句如下; 
  36.  
  37. Select Count(Tmp.Id) 
  38. From (Select Rownum As Id, t.Entry_Id, t.Container_Id, Con.Container_Num 
  39.              From AEC t 
  40.              Inner Join AEH Head On t.Entry_Id = Head.Entry_Id And Head.Entry_Id = :B2 --迁移条件Head.Entry_Id = :B2到此处 
  41.              Inner Join AC Con On t.Container_Id = Con.Id And Head.Deleted_Flag = '0' And Con.Deleted_Flag = '0'  
  42.              And con.Container_Num = :B1) Tmp   --迁移条件con.Container_Num = :B1到此处 
  43.        Inner Join ACSN Constatus On Tmp.Container_Id = Constatus.Container_Id And 
  44.        Constatus.Px_Operation_Status <> '0'  
  45.        --And Tmp.Entry_Id = :B2  
  46.        --And Tmp.Container_Num = :B1 
  47.  
  48. 实测结果表明,COST已经下降到了9,提升近500倍,相信这个效果是大家乐意接受的。 
  49.  
  50. SELECT STATEMENT, GOAL = ALL_ROWS                                Cost=9  Cardinality=1   Bytes=33 
  51.  SORT AGGREGATE                                              Cardinality=1   Bytes=33 
  52.   NESTED LOOPS                                           Cost=9  Cardinality=1   Bytes=33 
  53.    VIEW  Object owner=TEST                                    Cost=7  Cardinality=1   Bytes=26 
  54.     COUNT                    
  55.      NESTED LOOPS                                        Cost=7  Cardinality=1   Bytes=64 
  56.       NESTED LOOPS                                       Cost=5  Cardinality=1   Bytes=44 
  57.        TABLE ACCESS BY INDEX ROWID  Object owner=TEST   Object name=AEH          Cost=3  Cardinality=1   Bytes=21 
  58.         INDEX UNIQUE SCAN        Object owner=TEST   Object name=PK_AEH       Cost=2  Cardinality=1    
  59.        INDEX RANGE SCAN          Object owner=TEST   Object name=IDX_A_E_C       Cost=2  Cardinality=1   Bytes=23 
  60.       TABLE ACCESS BY INDEX ROWID   Object owner=TEST   Object name=AC           Cost=2  Cardinality=1   Bytes=20 
  61.        INDEX UNIQUE SCAN         Object owner=TEST   Object name=IDX_C        Cost=1  Cardinality=1    
  62.    TABLE ACCESS BY INDEX ROWID      Object owner=TEST   Object name=ACSN         Cost=2  Cardinality=1   Bytes=7 
  63.     INDEX UNIQUE SCAN            Object owner=TEST   Object name=FK_A_C_C_S_P    Cost=1  Cardinality=1    
本文转自zylhsy 51CTO博客,原文链接:http://blog.51cto.com/yunlongzheng/574394,如需转载请自行联系原作者
相关文章
|
9天前
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
6天前
|
SQL 监控 关系型数据库
SQL语句当前及历史信息查询-performance schema的使用
本文介绍了如何使用MySQL的Performance Schema来获取SQL语句的当前和历史执行信息。Performance Schema默认在MySQL 8.0中启用,可以通过查询相关表来获取详细的SQL执行信息,包括当前执行的SQL、历史执行记录和统计汇总信息,从而快速定位和解决性能瓶颈。
|
18天前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
61 10
|
11天前
|
SQL 关系型数据库 MySQL
|
16天前
|
SQL 存储 缓存
SQL Server 数据太多如何优化
11种优化方案供你参考,优化 SQL Server 数据库性能得从多个方面着手,包括硬件配置、数据库结构、查询优化、索引管理、分区分表、并行处理等。通过合理的索引、查询优化、数据分区等技术,可以在数据量增大时保持较好的性能。同时,定期进行数据库维护和清理,保证数据库高效运行。
|
18天前
|
SQL
SQL JOIN
【11月更文挑战第06天】
35 4
|
25天前
|
SQL 数据库 开发者
功能发布-自定义SQL查询
本期主要为大家介绍ClkLog九月上线的新功能-自定义SQL查询。
|
24天前
|
SQL 关系型数据库 MySQL
图解 SQL 里的各种 JOIN
用文氏图表示 SQL 里的各种 JOIN,一下子就理解了。
33 2
|
30天前
|
SQL 资源调度 分布式计算
如何让SQL跑快一点?(优化指南)
这篇文章主要探讨了如何在阿里云MaxCompute(原ODPS)平台上对SQL任务进行优化,特别是针对大数据处理和分析场景下的性能优化。
|
21天前
|
SQL 关系型数据库 MySQL
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
mysql编写sql脚本:要求表没有主键,但是想查询没有相同值的时候才进行插入
30 0