oracle pushpred,Oracle优化-leading提示和ordered提示以及materialize提示

最新推荐文章于 2021-08-31 16:35:33 发布
最新推荐文章于 2021-08-31 16:35:33 发布
阅读量1.2k 收藏
点赞数
文章标签： oracle pushpred
本文讨论了一个Oracle查询在执行时遇到的性能问题，主要原因是笛卡尔乘积导致的效率低下。通过分析执行计划，提出了重新收集统计信息、使用LEADING提示和MATERIALIZED视图等解决方案。实验表明，LEADING提示和MATERIALIZED视图可以显著提高查询速度，将执行时间从几十秒降低到0.17秒至0.2秒。这为数据库性能调优提供了一定的思路和实践方法。
摘要由CSDN通过智能技术生成

以下内容适用于Oracle 10.2.0.5及其以上版本

一个查询很慢，原始SQL如下：

select

a.*

from (select

ssi.ID,

'small_station_info' TB,

(select sbi.name

from scene_base_info sbi

where sbi.id = ssi.antenna_selection) as antenna_selection,

ssi.antenna_height,

ssi.down_angle,

ssi.azimuth_angle,

ssi.ITI_ID,

sa.longitude,

sa.latitude,

sa.attach_id

from consolidation_demand cd

left join demand_test_info dti

on cd.id = dti.cd_id

left join demand_plan_info dpi

on dti.id = dpi.tdl_id

left join building_plan_info bpi

on dpi.id = bpi.dpi_id

left join NEAR_FAR_PLACE_INFO nfpi

on bpi.id = nfpi.bpi_id

left join SMALL_STATION_INFO ssi

on nfpi.id = ssi.nfpi_id

left join site_attachment sa

on TO_NUMBER(sa.longitude) is not null

AND TO_NUMBER(sa.latitude) > 26.074423

AND TO_NUMBER(sa.latitude) < 26.077573

AND TO_NUMBER(sa.longitude) > 119.191148

AND TO_NUMBER(sa.longitude) < 119.197649

AND sa.attach_name =

substr(ssi.AZIMUTH_ANGLE_PHOTO,

instr(ssi.AZIMUTH_ANGLE_PHOTO, '/', -1) + 1,

length(ssi.AZIMUTH_ANGLE_PHOTO))) a

where a.longitude is not null

表都不大，执行计划如下：

已选择 12 行。

执行计划

----------------------------------------------------------

Plan hash value: 1917963167

---------------------------------------------------------------------------------------------------------------

| Id  | Operation                          | Name                    | Rows  | Bytes | Cost (%CPU)| Time    |

---------------------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT                    |                        |    1 |  253 |  519  (2)| 00:00:07 |

|  1 |  TABLE ACCESS BY INDEX ROWID        | SCENE_BASE_INFO        |    1 |    14 |    1  (0)| 00:00:01 |

|*  2 |  INDEX UNIQUE SCAN                | SCENE_BASE_INFO_PK      |    1 |      |    0  (0)| 00:00:01 |

|  3 |  VIEW                              |                        |    1 |  253 |  519  (2)| 00:00:07 |

|*  4 |  FILTER                            |                        |      |      |            |      |

|*  5 |    HASH JOIN OUTER                  |                        |    1 |  251 |  519  (2)| 00:00:07 |

|*  6 |    HASH JOIN OUTER                |                        |    83 |  8134 |  505  (1)| 00:00:07 |

|*  7 |      HASH JOIN OUTER                |                        |    83 |  7304 |  501  (1)| 00:00:07 |

|*  8 |      HASH JOIN OUTER              |                        |    83 |  6391 |  493  (1)| 00:00:06 |

|*  9 |        HASH JOIN OUTER              |                        |    83 |  5478 |  271  (1)| 00:00:04 |

|  10 |        MERGE JOIN CARTESIAN        |                        |    36 |  2052 |    21  (0)| 00:00:01 |

|* 11 |          TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT        |    1 |    53 |    16  (0)| 00:00:01 |

|* 12 |          INDEX RANGE SCAN          | IDX_SITE_ATTACHMENT_JWD |    1 |      |    15  (0)| 00:00:01 |

|  13 |          BUFFER SORT                |                        |  6725 | 26900 |    5  (0)| 00:00:01 |

|  14 |          INDEX FAST FULL SCAN      | PK_CONSOLIDATION_DEMAND |  6725 | 26900 |    5  (0)| 00:00:01 |

|  15 |        TABLE ACCESS FULL          | DEMAND_TEST_INFO        | 15459 |  135K|  249  (1)| 00:00:03 |

|  16 |        TABLE ACCESS FULL            | DEMAND_PLAN_INFO        |  8787 | 96657 |  221  (1)| 00:00:03 |

|  17 |      TABLE ACCESS FULL            | BUILDING_PLAN_INFO      |  3244 | 35684 |    8  (0)| 00:00:01 |

|  18 |      TABLE ACCESS FULL              | NEAR_FAR_PLACE_INFO    |  389 |  3890 |    3  (0)| 00:00:01 |

|  19 |    TABLE ACCESS FULL              | SMALL_STATION_INFO      |  594 | 90882 |    13  (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

- access("SBI"."ID"=:B1)

- filter("SA"."ATTACH_NAME"=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PHOTO",'

/',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))

- access("NFPI"."ID"="SSI"."NFPI_ID"(+))

- access("BPI"."ID"="NFPI"."BPI_ID"(+))

- access("DPI"."ID"="BPI"."DPI_ID"(+))

- access("DTI"."ID"="DPI"."TDL_ID"(+))

- access("CD"."ID"="DTI"."CD_ID"(+))

- filter("SA"."LONGITUDE" IS NOT NULL)

- access(TO_NUMBER("LONGITUDE")>119.191148 AND TO_NUMBER("LATITUDE")>26.074423 AND

TO_NUMBER("LONGITUDE")<119.197649 AND TO_NUMBER("LATITUDE")<26.077573)

filter(TO_NUMBER("LONGITUDE") IS NOT NULL AND TO_NUMBER("LATITUDE")<26.077573 AND

TO_NUMBER("LATITUDE")>26.074423)

这个执行计划，看起来无比正常，应该要left join的都有。

但问题的关键在于10 步骤-- MERGE JOIN CARTESIAN。笛卡尔乘积的排序合并连接，这个需要耗费很长时间。

等待这个结果要耗费几十秒，甚至要更久！

如何解决这样的问题，有以下几个方法：

重新收集每个表的统计数据--这个没有实验过，但即使那么做，可能也无效。不过从本例看，很有可能是这个导致的。

启用leading提示，结合其它提示

使用materialize提示

使用leading提示

select /*+ no_merge(a) no_push_pred(a) */

a.*

from (select

/*+ leading(cd dti dpi bpi ssi) */

...) a

where a.longitude is not null

/

执行计划

已选择 12 行。

执行计划

----------------------------------------------------------

Plan hash value: 1844304918

---------------------------------------------------------------------------------------------------------

| Id  | Operation                    | Name                    | Rows  | Bytes | Cost (%CPU)| Time  |

---------------------------------------------------------------------------------------------------------

|  0 | SELECT STATEMENT              |                        |    1 |  253 |  520  (2)| 00:00:07 |

|  1 |  TABLE ACCESS BY INDEX ROWID  | SCENE_BASE_INFO        |    1 |    14 |    1  (0)| 00:00:01 |

|*  2 |  INDEX UNIQUE SCAN          | SCENE_BASE_INFO_PK      |    1 |      |    0  (0)| 00:00:01 |

|  3 |  VIEW                        |                        |    1 |  253 |  520  (2)| 00:00:07 |

|*  4 |  HASH JOIN                  |                        |    1 |  251 |  520  (2)| 00:00:07 |

|*  5 |    TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT        |    1 |    53 |    16  (0)| 00:00:01 |

|*  6 |    INDEX RANGE SCAN          | IDX_SITE_ATTACHMENT_JWD |    1 |      |    15  (0)| 00:00:01 |

|*  7 |    HASH JOIN RIGHT OUTER      |                        | 23606 |  4564K|  503  (2)| 00:00:07 |

|  8 |    TABLE ACCESS FULL        | SMALL_STATION_INFO      |  594 | 90882 |    13  (0)| 00:00:01 |

|*  9 |    HASH JOIN RIGHT OUTER    |                        | 15459 |  679K|  490  (2)| 00:00:06 |

|  10 |      TABLE ACCESS FULL        | NEAR_FAR_PLACE_INFO    |  389 |  3890 |    3  (0)| 00:00:01 |

|* 11 |      HASH JOIN RIGHT OUTER    |                        | 15459 |  528K|  486  (2)| 00:00:06 |

|  12 |      TABLE ACCESS FULL      | BUILDING_PLAN_INFO      |  3244 | 35684 |    8  (0)| 00:00:01 |

|* 13 |      HASH JOIN RIGHT OUTER  |                        | 15459 |  362K|  477  (1)| 00:00:06 |

|  14 |        TABLE ACCESS FULL      | DEMAND_PLAN_INFO        |  8787 | 96657 |  221  (1)| 00:00:03 |

|* 15 |        HASH JOIN OUTER        |                        | 15459 |  196K|  255  (1)| 00:00:04 |

|  16 |        INDEX FAST FULL SCAN  | PK_CONSOLIDATION_DEMAND |  6725 | 26900 |    5  (0)| 00:00:01 |

|  17 |        TABLE ACCESS FULL    | DEMAND_TEST_INFO        | 15459 |  135K|  249  (1)| 00:00:03 |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

- access("SBI"."ID"=:B1)

- access("SA"."ATTACH_NAME"=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PH

OTO",'/',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))

- filter("SA"."LONGITUDE" IS NOT NULL)

- access(TO_NUMBER("LONGITUDE")>119.191148 AND TO_NUMBER("LATITUDE")>26.074423 AND

TO_NUMBER("LONGITUDE")<119.197649 AND TO_NUMBER("LATITUDE")<26.077573)

filter(TO_NUMBER("LONGITUDE") IS NOT NULL AND TO_NUMBER("LATITUDE")<26.077573 AND

TO_NUMBER("LATITUDE")>26.074423)

- access("NFPI"."ID"="SSI"."NFPI_ID"(+))

- access("BPI"."ID"="NFPI"."BPI_ID"(+))

- access("DPI"."ID"="BPI"."DPI_ID"(+))

- access("DTI"."ID"="DPI"."TDL_ID"(+))

- access("CD"."ID"="DTI"."CD_ID"(+))

没有笛卡尔的merge join .步骤4还是一个hash join 。

执行很快，大概可以0.17秒

使用materialize提示

1 WITH A AS

2 (select /*+MATERIALIZE*/

3 .....)4 select a.* from A WHERE a.longitude is not null

执行计划

已选择 12 行。

执行计划

----------------------------------------------------------

Plan hash value: 3536941173

--------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

--------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 23606 | 5832K| 700 (2)| 00:00:09 |

| 1 | TEMP TABLE TRANSFORMATION | | | | | |

| 2 | LOAD AS SELECT | | | | | |

|* 3 | HASH JOIN RIGHT OUTER | | 23606 | 5786K| 520 (2)| 00:00:07 |

| 4 | TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT | 1 | 53 | 16 (0)| 00:00:01 |

|* 5 | INDEX RANGE SCAN | IDX_SITE_ATTACHMENT_JWD | 1 | | 15 (0)| 00:00:01 |

|* 6 | HASH JOIN RIGHT OUTER | | 23606 | 4564K| 503 (2)| 00:00:07 |

| 7 | TABLE ACCESS FULL | SMALL_STATION_INFO | 594 | 90882 | 13 (0)| 00:00:01 |

|* 8 | HASH JOIN RIGHT OUTER | | 15459 | 679K| 490 (2)| 00:00:06 |

| 9 | TABLE ACCESS FULL | NEAR_FAR_PLACE_INFO | 389 | 3890 | 3 (0)| 00:00:01 |

|* 10 | HASH JOIN RIGHT OUTER | | 15459 | 528K| 486 (2)| 00:00:06 |

| 11 | TABLE ACCESS FULL | BUILDING_PLAN_INFO | 3244 | 35684 | 8 (0)| 00:00:01 |

|* 12 | HASH JOIN RIGHT OUTER | | 15459 | 362K| 477 (1)| 00:00:06 |

| 13 | TABLE ACCESS FULL | DEMAND_PLAN_INFO | 8787 | 96657 | 221 (1)| 00:00:03 |

|* 14 | HASH JOIN OUTER | | 15459 | 196K| 255 (1)| 00:00:04 |

| 15 | INDEX FAST FULL SCAN | PK_CONSOLIDATION_DEMAND | 6725 | 26900 | 5 (0)| 00:00:01 |

| 16 | TABLE ACCESS FULL | DEMAND_TEST_INFO | 15459 | 135K| 249 (1)| 00:00:03 |

|* 17 | VIEW | | 23606 | 5832K| 180 (2)| 00:00:03 |

| 18 | TABLE ACCESS FULL | SYS_TEMP_0FD9D68A2_721EF047 | 23606 | 4103K| 180 (2)| 00:00:03 |

--------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("SA"."ATTACH_NAME"(+)=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PHOT

O",'/',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))

5 - access(TO_NUMBER("LONGITUDE"(+))>119.191148 AND TO_NUMBER("LATITUDE"(+))>26.074423 AND

TO_NUMBER("LONGITUDE"(+))<119.197649 AND TO_NUMBER("LATITUDE"(+))<26.077573)

filter(TO_NUMBER("LONGITUDE"(+)) IS NOT NULL AND TO_NUMBER("LATITUDE"(+))<26.077573 AND

TO_NUMBER("LATITUDE"(+))>26.074423)

6 - access("NFPI"."ID"="SSI"."NFPI_ID"(+))

8 - access("BPI"."ID"="NFPI"."BPI_ID"(+))

10 - access("DPI"."ID"="BPI"."DPI_ID"(+))

12 - access("DTI"."ID"="DPI"."TDL_ID"(+))

14 - access("CD"."ID"="DTI"."CD_ID"(+))

17 - filter("A"."LONGITUDE" IS NOT NULL)

也很快，大约0.19~0.2左右。

之所以慢，主要是因为要先生成gt表 SYS_TEMP_0FD9D68A2_721EF047。

总结

1.最好先收集统计数据

2.在收集统计数据无效的情况下，考虑使用leading提示，其次materialize提示也会破坏oracle优化器一些自以为明智的计划(优化器的不足，oracle已经提到了，这就是hint的由来)

3.dba要优化一个库，不是一个很容易的事情，需要做很多工作。

0b1331709591d260c1c78e86d0c51c18.png

weixin_39803022
关注
【云原生进阶之数据库技术】第二章-Oracle-使用-3.4.2-Oracle Active Data Guard调优
junbaozi的专栏
05-29 1643
Oracle Active Data Guard（ADG）调优涉及多个层面，旨在确保备用数据库在提供实时查询服务的同时，维持高效的数据同步与良好的系统性能。为了确保ADG环境的高性能和可靠性，需要进行适当的调优。以下是一些关键的调优领域和建议：调优是一项持续的过程，需要根据实际业务需求、系统负载变化以及新版本特性的引入进行适时调整。在进行任何调优操作之前，务必做好备份、制定回滚计划，并在非业务高峰期进行测试验证。
【云原生进阶之数据库技术】第二章-Oracle-使用-3.5-Oracle中hint使用
最新发布
junbaozi的专栏
05-29 841
Hint实际上是一种特殊的注释，它以一种固定的格式和位置出现在SQL语句的SQL文本中，可以影响优化器对于执行计划的选择，但这种影响不是强制性的，优化器在某些情况下也可能忽略目标SQL中的Hint，即使这个Hint在语法和语义上是有效的。如果目标SQL的SQL文本中出现了Hint，优化器在选择最终执行计划时会把Hint一并考虑进来，如果优化器判断这个Hint给出的建议是合适的，就会直接遵循这个Hint给出的建议，并据此选定执行计划。反之，则会忽略该Hint仍然采用原先的判断标准来选定执行计划。
oracle view占资源,关于VIEW PUSHED PREDICATE的一个优化案例
weixin_30676635的博客
04-08 799
根据这个案例需要的一些知识，后面会跟进关于外联结、视图合并、VIEW PUSHED PREDICATE的相关知识。早上某数据库服务器CPU不断报警，应用系统管理员同时反馈应用响应明显变慢。登陆数据库主机查看，应用连接上来的几个进程占用了大量的CPU资源，造成CPU空闲率很低。登陆数据库查询，发现有不少buffer cache chains的等待，初步判断是应用上出现了某些性能糟糕的SQL语句。通过...
oracle hint push_pred,提示用法：push_pred
weixin_29799209的博客
04-04 938
提示用法：push_pred使用条件：基表为临时表，左连接一个基本两张大表的UNION ALL视图，关联的字段有索引，oracle默认不会使用索引。但使用push_pred提示就能实现用索引访问，初步分析有两个原因：1、oracle不清楚临时表中的记录数目。2、视图为UNION视图，oracle对此类视图的索引支持也不是太好。[@more@]提示用法：push_pred使用条件：基表为临时表，左连...
oracle hint push_pred,Oracle Hint List
weixin_31304817的博客
04-04 129
ALL_ROWSAND_EQUALANTIJOINAPPENDBITMAPBUFFERBYPASS_RECURSIVE_CHECKBYPASS_UJVCCACHECACHE_CBCACHE_TEMP_TABLECARDINALITYCHOOSECIV_GBCOLLECTIONS_GET_REFSCPU_COSTINGCUBE_GBCURSOR_SHARING_EXACTDEREF_NO_REWRI...
oracle优化-leading提示和ordered提示以及materialize提示
weixin_34096182的博客
07-07 341
以下内容适用于oracle 10.2.0.5及其以上版本 一个查询很慢，原始SQL如下： 1 select 2 a.* 3 from (select 4 ssi.ID, 5 'small_station_info' TB, 6 (select sbi.name 7 ...
oracle hint_leading
12-20 498
oracle hint_leading_merge1,leading 1,比ordered功能更多 2,如下明确看出leading可以发变首表 3,如果指定了ordered,优先级高于leading ...
学习ORACLE-优化器提示（Hints）
找个地方记笔记
05-09 1938
数据仓库中加工数据时，经常会使用提示（HINT）指示优化器改变执行路径，以便快速的得到数据
oracle分页优化 ---- rowid方法
猴子的故事
04-08 970
<br />了解到DBA对oracle的分页方法进行优化，所以补充一个加强版！<br />假设activity_pepsi_dream表拥有 id, nick, auction_url, gmt_create 字段。<br /> <br /> <br />--普通写法（显示1-50页）<br />select id, nick, auction_url, gmt_create<br />from (select id, nick, auction_url, gmt_create, rownum linenu
oracle 性能优化--索引总结
数据挖掘工人
09-30 3985
索引是建立在表的一列或多个列上的辅助对象，目的是加快访问表中的数据；     Oracle存储索引的数据结构是B*树，位图索引也是如此，只不过是叶子节点不同B*数索引；     索引由根节点、分支节点和叶子节点组成，上级索引块包含下级索引块的索引数据，叶节点包含索引数据和确定行实际位置的rowid。 使用索引的目的： 加快查询速度 减少I/O操作 消除磁盘排序
Oracle VIEW PUSHED PREDICATE案例分析
dbhang的博客
08-31 990
SELECT * FROM (SELECTA.INVOICE_ID, A.VENDOR_ID, A.INVOICE_NUM, A.INVOICE_AMOUNT, A.GL_DATE, A.INVOICE_CURRENCY_CODE, SUM(NVL(B.PREPAY_AMOUNT_APPLIED,0)) PAID_AMOUNT
oracle hint push_pred,oracle三组难缠的hint no_unnest/unnest,push_subq,push_pred
weixin_39653448的博客
04-04 381
最近在看一个哥们优化sql里面,使用到了几个特殊的hint，但我总是对此不解，所以针对此问题自己做了一些测试(参考了一些资料)1. no_unnest, unnestunnest我们称为对子查询展开，顾名思义，就是别让子查询孤单地嵌套(nest)在里面。所以un_unnest双重否定代表肯定，即让子查询不展开，让它嵌套(nest)在里面。如果一个查询中的where 中出现 view 或者 子查询...
oracle leading(),oracle hint中ordered 和leading原理很好的帖子
weixin_39541844的博客
04-05 613
问题：请教HINT写法我有一个SQL添加如下hint,目的是指定hash_join方式。select /*+ordered use_hash(a,b,c,d) */ *from a,b,c,dWhere ...其中,a只与b有关联关系，b只与c有关联关系，b只与c有关联关系,c只与d有关联关系，数量级：a:1000条,b:100 万条， c:800万条 ， d：100万条执行计划为：Hash ...
谓词推入(pushing predicate)
liujinwei2005的专栏
06-23 780
谓词推入(PUSHINGPREDICATE) PushingPredicate(谓词推入)：当SQL语句中包含有不能合并的视图，并且视图有谓词过滤(也就是where过滤条件)，CBO会将where过滤条件推入视图中，这个就叫做谓词推入。谓词推入的主要目的就是让Oracle尽可能早的过滤掉无用的数据，从而提升查询性能。 下面举个例子(本例基于Scott用户Oracle11gR2): create or replace view emp1 as select /*+NO_MERGE */ena..
Oracle hint Leading 的使用
有梦就别怕痛
05-16 1万+
Leading()： 指示Oracle在执行join(hash join, nested loop join, merge join)时的连接顺序。当执行计划不按照最优的表连接顺序时，考虑使用Leading 改变执行计划。eg:select v.*, t.* from v_view1 ,(select  /*+ leading(t1, tftc) */ * from tftc, t1 where ...
oracle leading(),Oracle leading vs. ordered hints
weixin_42516490的博客
04-05 336
The"ordered" hint is extremely useful forcutting-down query parse time and ensuringproper table join order for static tables andqueries./* LEADING */ Hint– specifies the set oftables to be used as the...
oracle 使用leading, use_nl, rownum调优
巫山云的专栏
08-26 7299
1、使用leading和use_nl来设置表的查询顺序，来加快查询速度，一般把小表设为第一个表。 /*+LEADING(TABLE)*/ 　　将指定的表作为连接次序中的首表. /*+USE_NL(TABLE)*/ 　　将指定表与嵌套的连接的行源进行连接,并把指定表作为内部表. 成本计算方法： 设小表100行，大表100000行。 两表均有索引： 如果小表在内，大表在外(驱动表)
oracle leading(),Oracle HowTo:如何使用Leading提示改变表连接方式
weixin_34568147的博客
04-05 1098
在多表联合查询中,当使用Ordered提示改变SQL执行计划之后,通常我们很难再次控制结果集中进一步Join的顺序.这时候我们可以使用Oracle提供的另外一个Hints: Leading 提示.这个Hints在Oracle9i中的含义为:The LEADING hint causes Oracle to use the specified table as the first table in ...
oracle hint中ordered 和leading原理很好的帖子
热门推荐
枫$叶的专栏
05-05 1万+
问题：请教HINT写法我有一个SQL添加如下hint,目的是指定hash_join方式。select /*+ordered use_hash(a,b,c,d) */ *From a,b,c,dWhere ...其中,      a只与b有关联关系，b只与c有关联关系，b只与c有关联关系,c只与d有关联关系，    数量级：a:1000条,  b:100 万条， c:800万条 ， d：100万
Oracle SQL优化：强制NL连接驱动表的提示技巧
同时，文中还涵盖了Oracle内存结构、SQL执行过程以及优化策略，如数据读取方式、表连接实现和SQL的解析与执行。" 在Oracle数据库中，执行计划对于SQL查询的性能至关重要。NL连接是一种常用的表连接方式，它将一个表...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值