在 oracle 中，具有多个连接的查询执行需要更多时间
Posted
技术标签:
【中文标题】在 oracle 中，具有多个连接的查询执行需要更多时间【英文标题】：Query Execution with multiple joins is taking more time in oracle 【发布时间】：2019-03-05 08:06:40 【问题描述】：我们正在尝试在 Oracle 数据库中执行查询。执行需要 5 秒。所有列都已编入索引。
select
count(*)
from
ehub_mbr_sds.ehub_sds_mbr a
join
ehub_mbr_sds.ehub_sds_mbr_cntrct b
on a.ehub_mbr_id = b.ehub_mbr_id
join
ehub_mbr_sds.ehub_sds_cntrct d
on b.cntrct_id = d.cntrct_id
JOIN
EHUB_MBR_SDS.EHUB_SDS_CVRG c
ON b.EHUB_MBR_CNTRCT_ID= c.EHUB_MBR_CNTRCT_ID
JOIN
EHUB_MBR_SDS.EHUB_SDS_ELGBLTY f
ON f.PROD_CD= c.PROD_CD
JOIN
ehub_mbr_sds.ehub_sds_grp e
on d.ehub_grp_id = e.ehub_grp_id
where
a.sor_cd ='****'
AND e.GRP_ID='****' --need indexes for GRPID
AND c.sub_grp_id='*****'
and f.plan_type_cd in('***')
and CURRENT_TIMESTAMP > c.cvrg_efctv_dt
and CURRENT_TIMESTAMP > c.cvrg_trmntn_dt
order by
b.hcid;
任何指针都会有所帮助
【问题讨论】：
这些表平均有多少数据？您选择了多少数据，可能需要全表扫描，数据是如何分布的，我可以建议运行调整顾问什么（注意是否需要许可证）select count(*) 结合order by 没有意义
显示执行计划和你拥有的索引。
5.5 k 计数正在返回
按性能移除订单仍然不好
【参考方案1】：
发布解释计划。同时，使用并行性重试查询，并在您的选择前提供提示。 I.E.
select /*+parallel*/...
通过在有和没有提示的情况下获取解释计划来确保并行性正常工作。 （可能您的服务器未配置为并行执行）
【讨论】：
我会谨慎使用并行性来加快 5 秒的查询。并行查询在进程启动、关闭和协调方面有很多开销，并且动态采样的解析时间增加。有可能提高 5 秒查询的运行时间，但如果总数据库时间显着增加，是否值得？ Oracle 并行性很棒，但我认为 OP 应该先让查询更智能地工作，然后再让它更努力地工作。 增加了解释计划，能不能帮忙分析一下 提及动态采样...“它通常用于补偿丢失或不足的统计信息，否则会导致非常糟糕的计划。对于查询中的一个或多个表确实如此的情况没有统计信息，优化器使用 DS 在优化语句之前收集这些表的基本统计信息。”也许收集一些统计数据？ 添加了动态静态 = 4，希望对您有所帮助【参考方案2】：SYS_EXTRACT_UTC(INTERNAL_FUNCTION("C"."CVRG_TRMNTN_DT"))<SYS_EXTRACT_UTC(CURRENT_TIMESTAMP(6)))
- 4 Sql Plan Directives used for this statement
- Degree of Parallelism is 4 because of hint
- dynamic statistics used: dynamic sampling (level=4)
- this is an adaptive plan
14 - filter(SYS_EXTRACT_UTC(INTERNAL_FUNCTION("C"."CVRG_EFCTV_DT"))<SYS_EXTRACT_UTC(CURRENT_TIMESTAMP(6)) AND
19 - access("C"."SUB_GRP_ID"='****')
21 - access("B"."EHUB_MBR_CNTRCT_ID"="C"."EHUB_MBR_CNTRCT_ID")
22 - filter("D"."EHUB_GRP_ID" IS NOT NULL)
23 - access("B"."CNTRCT_ID"="D"."****")
24 - filter("E"."GRP_ID"='****')
25 - access("E"."EHUB_GRP_ID"="D"."*****")
26 - filter("A"."SOR_CD"='***')
27 - access("A"."EHUB_MBR_ID"="B"."*****")
28 - access("F"."PROD_CD"="C"."*****")
29 - filter("F"."PLAN_TYPE_CD"='****')
--------------------------------------------------------------------------------------------------------------------------------------------------------
Note
Plan hash value: 2232660988
Predicate Information (identified by operation id):
| 0 | SELECT STATEMENT | | 1 | 161 | 2775 (1)| 00:00:01 | | | |
| 1 | SORT AGGREGATE | | 1 | 161 | | | | | |
| 2 | PX COORDINATOR | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10003 | 1 | 161 | | | Q1,03 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | 161 | | | Q1,03 | PCWP | |
| 5 | NESTED LOOPS | | 1 | 161 | 2775 (1)| 00:00:01 | Q1,03 | PCWP | |
| 6 | NESTED LOOPS | | 12 | 161 | 2775 (1)| 00:00:01 | Q1,03 | PCWP | |
| 7 | NESTED LOOPS | | 1 | 147 | 2771 (1)| 00:00:01 | Q1,03 | PCWP | |
| 8 | NESTED LOOPS | | 1 | 128 | 2771 (1)| 00:00:01 | Q1,03 | PCWP | |
| 9 | NESTED LOOPS | | 1 | 108 | 2770 (1)| 00:00:01 | Q1,03 | PCWP | |
| 10 | NESTED LOOPS | | 1 | 92 | 2770 (1)| 00:00:01 | Q1,03 | PCWP | |
| 11 | BUFFER SORT | | | | | | Q1,03 | PCWC | |
| 12 | PX RECEIVE | | | | | | Q1,03 | PCWP | |
| 13 | PX SEND HASH | :TQ10001 | | | | | Q1,01 | P->P | HASH |
| 15 | BUFFER SORT | | | | | | Q1,01 | PCWC | |
| 16 | PX RECEIVE | | 3845 | | 9 (0)| 00:00:01 | Q1,01 | PCWP | |
| 17 | PX SEND HASH (BLOCK ADDRESS) | :TQ10000 | 3845 | | 9 (0)| 00:00:01 | Q1,00 | S->P | HASH (BLOCK|
| 18 | PX SELECTOR | | | | | | Q1,00 | SCWC | |
| 20 | TABLE ACCESS BY INDEX ROWID | EHUB_SDS_MBR_CNTRCT | 1 | 39 | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
|* 14 | TABLE ACCESS BY INDEX ROWID BATCHED| EHUB_SDS_CVRG | 1 | 53 | 2769 (1)| 00:00:01 | Q1,01 | PCWP | |
|* 19 | INDEX RANGE SCAN | IX4_EHUB_SDS_CVRG | 3845 | | 9 (0)| 00:00:01 | Q1,00 | SCWP | |
|* 21 | INDEX UNIQUE SCAN | PK_EHUB_SDS_MBR_CNTRCT | 1 | | 0 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 22 | TABLE ACCESS BY INDEX ROWID | EHUB_SDS_CNTRCT | 1 | 16 | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 23 | INDEX UNIQUE SCAN | PK_EHUB_SDS_CNTRCT | 1 | | 0 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 24 | TABLE ACCESS BY INDEX ROWID | EHUB_SDS_GRP | 1 | 20 | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 25 | INDEX UNIQUE SCAN | PK_EHUB_SDS_GRP | 1 | | 0 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 26 | TABLE ACCESS BY INDEX ROWID | EHUB_SDS_MBR | 1 | 19 | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 27 | INDEX UNIQUE SCAN | PK_EHUB_SDS_MBR | 1 | | 0 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 28 | INDEX RANGE SCAN | IX3_EHUB_SDS_ELGBLTY | 12 | | 1 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 29 | TABLE ACCESS BY INDEX ROWID | EHUB_SDS_ELGBLTY | 990 | 13860 | 3 (0)| 00:00:01 | Q1,03 | PCWP | |
【讨论】：
以上是关于在 oracle 中，具有多个连接的查询执行需要更多时间的主要内容，如果未能解决你的问题，请参考以下文章