中国领先的IT技术网站
|
|

Oracle中connect by语句的优化

很多应用中都会有类似组织机构的表,组织机构的表又通常是典型的层次结构(没有循环节点)。于是通过组织控制数据权限的时候,许多人都喜欢通过connect by获得组织信息,然后再过滤目标数据。

作者:lzfhope来源:Linux社区|2017-08-07 15:52

【51CTO活动】8.26 带你深度了解清华大学、搜狗基于算法的IT运维实践与探索


很多应用中都会有类似组织机构的表,组织机构的表又通常是典型的层次结构(没有循环节点)。于是通过组织控制数据权限的时候,许多人都喜欢通过connect by获得组织信息,然后再过滤目标数据。

在有些情况下,这样写并没有什么问题,但有些情况下,这个就是一个大问题。

归根结底,这是connect by特性导致的,Oracle无法知道connect by之后到底返回多少数据,所以有可能采取一些你所不期望的算法,结果自然不是你所期望的---非常慢。

下面,我就讨论在Oracle 12.1.0.2中如果遇到这样的语句应该如何处理。

为了很好理解,我做了3表:

执行SQL:

  1. SELECT A.CI, A.ENBAJ02 AS CELL_NAME 
  2.   FROM TDL_CM_CELL A, T_ORG_CELL_SCOPE S 
  3.  WHERE S.REGION_NAME = A.REGION_NAME 
  4.   AND S.CITY_NAME = A.CITY_NAME 
  5.   AND (S.ORG_ID) IN (SELECT ID 
  6.                         FROM T_ORG O 
  7.                       START WITH ID = 101021003 --1010210   
  8.                       --START WITH ID=1 
  9.                       CONNECT BY PARENT_ID = PRIOR ID) 

实际使用的执行计划:

而不会采用自适应计划(adaptive plan):

  1.  Plan Hash Value  : 2596385940  
  2.  
  3. ------------------------------------------------------------------------------------------------------------------- 
  4. | Id  | Operation                                       | Name                  | Rows | Bytes  | Cost | Time     | 
  5. ------------------------------------------------------------------------------------------------------------------- 
  6. |   0 | SELECT STATEMENT                                |                       | 2622 | 228114 |  227 | 00:00:01 | 
  7. |   1 |   NESTED LOOPS                                  |                       | 2622 | 228114 |  227 | 00:00:01 | 
  8. |   2 |    NESTED LOOPS                                 |                       | 2622 | 228114 |  227 | 00:00:01 | 
  9. | * 3 |     HASH JOIN                                   |                       |    1 |     31 |    7 | 00:00:01 | 
  10. |   4 |      VIEW                                       | VW_NSO_1              |    1 |     13 |    4 | 00:00:01 | 
  11. |   5 |       HASH UNIQUE                               |                       |    1 |     20 |    4 | 00:00:01 | 
  12. | * 6 |        CONNECT BY NO FILTERING WITH SW (UNIQUE) |                       |      |        |      |          | 
  13. |   7 |         TABLE ACCESS FULL                       | T_ORG                 |   75 |    825 |    3 | 00:00:01 | 
  14. |   8 |      TABLE ACCESS FULL                          | T_ORG_CELL_SCOPE      |   85 |   1530 |    3 | 00:00:01 | 
  15. | * 9 |     INDEX RANGE SCAN                            | IDX_TDL_CM_CELL_SCOPE |  257 |        |    8 | 00:00:01 | 
  16. |  10 |    TABLE ACCESS BY INDEX ROWID                  | TDL_CM_CELL           | 2313 | 129528 |  220 | 00:00:01 | 
  17. ------------------------------------------------------------------------------------------------------------------- 
  18.  
  19. Predicate Information (identified by operation id): 
  20. ------------------------------------------ 
  21. * 3 - access("S"."ORG_ID"="ID"
  22. * 6 - access("PARENT_ID"=PRIOR "ID"
  23. * 6 - filter("ID"=101021003) 
  24. * 9 - access("S"."REGION_NAME"="A"."REGION_NAME" AND "S"."CITY_NAME"="A"."CITY_NAME"
  25.  
  26.  
  27. Notes 
  28. ----- 
  29. - This is an adaptive plan 

原因在于,oracle无法知道connect by之后的数量,所以只能认为是很大的量

--

有一种方式就是,就是使用提示来解决:

  1. SELECT /*+ no_merge(x) use_nl(a x) */ 
  2.   A.CI, A.ENBAJ02 AS CELL_NAME 
  3.    FROM TDL_CM_CELL A, 
  4.         (select s.city_name, s.region_name 
  5.            from T_ORG_CELL_SCOPE S 
  6.           WHERE (S.ORG_ID) IN 
  7.                 (SELECT ID 
  8.                    FROM T_ORG O 
  9.                   START WITH ID = 101021003 --1010210   
  10.                  --START WITH ID=1 
  11.                  CONNECT BY PARENT_ID = PRIOR ID) 
  12.           
  13.          ) x 
  14.   where x.REGION_NAME = A.REGION_NAME 
  15.     AND x.CITY_NAME = A.CITY_NAME 

这样计划就是:

  1. Plan Hash Value  : 37846894  
  2.  
  3. --------------------------------------------------------------------------------------------------------------------- 
  4. | Id   | Operation                                        | Name                  | Rows | Bytes  | Cost | Time     | 
  5. --------------------------------------------------------------------------------------------------------------------- 
  6. |    0 | SELECT STATEMENT                                 |                       | 2313 | 277560 |  227 | 00:00:01 | 
  7. |    1 |   NESTED LOOPS                                   |                       | 2313 | 277560 |  227 | 00:00:01 | 
  8. |    2 |    NESTED LOOPS                                  |                       | 2313 | 277560 |  227 | 00:00:01 | 
  9. |    3 |     VIEW                                         |                       |    1 |     64 |    7 | 00:00:01 | 
  10. |  * 4 |      HASH JOIN                                   |                       |    1 |     31 |    7 | 00:00:01 | 
  11. |    5 |       VIEW                                       | VW_NSO_1              |    1 |     13 |    4 | 00:00:01 | 
  12. |    6 |        HASH UNIQUE                               |                       |    1 |     20 |    4 | 00:00:01 | 
  13. |  * 7 |         CONNECT BY NO FILTERING WITH SW (UNIQUE) |                       |      |        |      |          | 
  14. |    8 |          TABLE ACCESS FULL                       | T_ORG                 |   75 |    825 |    3 | 00:00:01 | 
  15. |    9 |       TABLE ACCESS FULL                          | T_ORG_CELL_SCOPE      |   85 |   1530 |    3 | 00:00:01 | 
  16. | * 10 |     INDEX RANGE SCAN                             | IDX_TDL_CM_CELL_SCOPE |  257 |        |    8 | 00:00:01 | 
  17. |   11 |    TABLE ACCESS BY INDEX ROWID                   | TDL_CM_CELL           | 2313 | 129528 |  220 | 00:00:01 | 
  18. --------------------------------------------------------------------------------------------------------------------- 
  19.  
  20. Predicate Information (identified by operation id): 
  21. ------------------------------------------ 
  22. * 4 - access("S"."ORG_ID"="ID"
  23. * 7 - access("PARENT_ID"=PRIOR "ID"
  24. * 7 - filter("ID"=101021003) 
  25. * 10 - access("X"."REGION_NAME"="A"."REGION_NAME" AND "X"."CITY_NAME"="A"."CITY_NAME")  

如果一个应用的start id可能是一个很大的范围,如果强制使用提示,也会出现问题,所以如果有这样的应用,可以考虑使用oracle 12c的adaptive特性。

如果不行,就必须把不同范围的查询,定义为不同的功能提交给用户。

【编辑推荐】

  1. Oracle基础教程之Merge into
  2. Oracle分区数据问题的分析和修复
  3. Mysql分页&关联查询优化
  4. 十招搞定MySQL大规模数据库的性能和伸缩性优化
  5. Oracle开源三个容器工具
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

读 书 +更多

框架设计(第2版)CLR Via C#

作为深受编程人员爱戴和尊敬的编程专家,微软.NET开发团队的顾问,本书作者Jeffrey Richter针对开发各种应用程序(如Web Form、Windows For...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× 官方软考报名与培训中心