Oracle中connectby语句的优化

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

十多年的土默特左旗网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销的优势是能够根据用户设备显示端的尺寸不同，自动调整土默特左旗建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“土默特左旗网站设计”,“土默特左旗网站推广”以来，每个客户项目都认真落实执行。

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

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

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

为了很好理解，我做了3表：

执行SQL:

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

实际使用的执行计划:

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

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

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

--

有一种方式就是，就是使用提示来解决：

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

这样计划就是：

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

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

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

文章题目：Oracle中connectby语句的优化
文章出自：http://www.shufengxianlan.com/qtweb/news13/480813.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

响应式网站知识

行业网站建设

达州电信机房　　 　成都ssl证书认证　　 　成都移动服务器托管　　 　香港云服务器　　 　网站设计制作报价　　 　九针服饰　　 　成都主机托管　　 　成都网站优化　　 　成都定制网站开发　　 　网站建设开发　　 　响应式网站设计　　 　成都移动服务器托管　　 　新都四新网站建设　　 　巴彦网站建设　　 　铁科精智测控　　 　重庆花箱　　 　营销推广　　 　四川成都网站设计　　 　消防工程　　 　雪茄烟