暂无图片
请大佬帮忙看看sql执行,执行速度较慢如何寻找问题点,帮忙给点建议
我来答
分享
黑暗舞步
2021-10-11
请大佬帮忙看看sql执行,执行速度较慢如何寻找问题点,帮忙给点建议
暂无图片 10M

查询SQL:

SELECT TRANS_DATETIME as transDatetime, TRANS_CODE as transCode, TRANS_MERCHANTNAME as transMerchantName, TRANS_AMT as transAmount, TRANS_TYPE as transType FROM CORE_SCHEMA.BUSI_TRANS trans LEFT JOIN CORE_SCHEMA.INSU_ACCOUNT_CHANGE_DETAIL accChange ON accChange.CHANGED_CHANGECODE = trans.TRANS_ACCCHANGECODE LEFT JOIN CORE_SCHEMA.ACCOUNT acc ON acc."ID" = accChange.CHANGED_ACCOUNT_ID LEFT JOIN CORE_SCHEMA.CUSTOMER customer ON customer."ID" = acc.CUSTOMER_ID LEFT JOIN CORE_SCHEMA.INSU_SLIP slip ON acc.SLIP_ID = slip.SLIP_ID WHERE slip.SLIP_CODE in ('ZGRSGWHN2020010701','ZGRSGWHN2020010702', 'ZGRSGWHN2020010703', 'ZGRSGWHN2020010704', 'ZGRSGWHN2020010705', 'ZGRSGWHN2020010706', 'ZGRSGWHN2020010707', 'ZGRSGWHN2020010708', 'ZGRSGWHN2020010709', 'ZGRSGWHN2020010710', 'ZGRSGWHN2020010711', 'ZGRSGWHN2020010712', 'ZGRSGWHN2020010713', 'ZGRSGWHN2020010714', 'ZGRSGWHN2020010715', 'ZGRSGWHN2020010716', 'ZGRSGWHN2020010717', 'ZGRSGWHN2020010718', 'ZGRSGWHN2020010719', 'ZGRSGWHN2020010720', 'ZGRSGWHN2020010721', 'ZGRSGWHN2020010722', 'ZGRSGWHN2020010723', 'ZGRSGWHN2020010724', '190G171EH64001F', '190G171EH64001E', '190G171EH64001E-202007', '2020430102DDD400348772', '2020430102DDD400348771', '190G171EH64001F2021', 'GSGWHNS20210101') and customer.CERTIFICATE = '433022197502160526' ORDER BY TRANS_DATETIME DESC;



执行计划:

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2802302807

--------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 18 | 3942 | 96005 (1)| 00:19:13 |
| 1 | SORT ORDER BY | | 18 | 3942 | 96005 (1)| 00:19:13 |
|* 2 | HASH JOIN | | 18 | 3942 | 96004 (1)| 00:19:13 |
|* 3 | HASH JOIN | | 19 | 1976 | 8035 (1)| 00:01:37 |
| 4 | NESTED LOOPS | | 2 | 124 | 858 (1)| 00:00:11 |
| 5 | NESTED LOOPS | | 3 | 124 | 858 (1)| 00:00:11 |
|* 6 | HASH JOIN | | 3 | 117 | 855 (1)| 00:00:11 |
|* 7 | TABLE ACCESS FULL | CUSTOMER | 1 | 24 | 205 (1)| 00:00:03 |
| 8 | TABLE ACCESS FULL | ACCOUNT | 173K| 2545K| 650 (1)| 00:00:08 |
|* 9 | INDEX UNIQUE SCAN | SYS_C0021222 | 1 | | 0 (0)| 00:00:01 |
|* 10 | TABLE ACCESS BY INDEX ROWID| INSU_SLIP | 1 | 23 | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS FULL | INSU_ACCOUNT_CHANGE_DETAIL | 1840K| 73M| 7172 (1)| 00:01:27 |
| 12 | TABLE ACCESS FULL | BUSI_TRANS | 1746K| 191M| 87965 (1)| 00:17:36 |
--------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("ACCCHANGE"."CHANGED_CHANGECODE"="TRANS"."TRANS_ACCCHANGECODE")
3 - access("ACC"."ID"="ACCCHANGE"."CHANGED_ACCOUNT_ID")
6 - access("CUSTOMER"."ID"="ACC"."CUSTOMER_ID")
7 - filter("CUSTOMER"."CERTIFICATE"='433022197502160526')
9 - access("ACC"."SLIP_ID"="SLIP"."SLIP_ID")
10 - filter("SLIP"."SLIP_CODE"='190G171EH64001E' OR "SLIP"."SLIP_CODE"='190G171EH64001E-202007' OR
"SLIP"."SLIP_CODE"='190G171EH64001F' OR "SLIP"."SLIP_CODE"='190G171EH64001F2021' OR
"SLIP"."SLIP_CODE"='2020430102DDD400348771' OR "SLIP"."SLIP_CODE"='2020430102DDD400348772' OR
"SLIP"."SLIP_CODE"='GSGWHNS20210101' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010701' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010702' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010703' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010704' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010705' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010706' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010707' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010708' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010709' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010710' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010711' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010712' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010713' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010714' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010715' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010716' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010717' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010718' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010719' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010720' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010721' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010722' OR "SLIP"."SLIP_CODE"='ZGRSGWHN2020010723' OR
"SLIP"."SLIP_CODE"='ZGRSGWHN2020010724')

我来答
添加附件
收藏
分享
问题补充
2条回答
默认
最新
chengang

返回记录太多。 BUSI_TRANS走了全表扫。

如果业务允许分页,那就分页。


不允许分页的话。你在 BUSI_TRANS表 建一个(TRANS_DATETIME,TRANS_DATETIME, TRANS_CODE , TRANS_MERCHANTNAME , TRANS_AMT , TRANS_TYPE,TRANS_ACCCHANGECODE )联后索引。应该能避免排序开销。也能走索引扫描吧。

暂无图片 评论
暂无图片 有用 1
打赏 0
流星

你用 sql tuning advisor 和sql access advisor来试试,就是让Oracle给出优化建议,不会的话网上一搜,墨天轮上一搜肯定有相关的文章

暂无图片 评论
暂无图片 有用 1
打赏 0
回答交流
Markdown


请输入正文
提交
相关推荐
rac怎么实现负载均衡
回答 1
参考一下这篇文章:https://mp.weixin.qq.com/s/GgAlpRbvSUezIrr5VUIPg
请问有试过在OGG目标端开启归档日志的么?会影响传输不?
回答 1
一般都会开的;归档其实不影响传输速度。当然前提是你机器性能还过得去。
Oracle 11g 数据库 备份数据量在1.1G左右 数据库从18年部署到现在没有优化过,最近两个月重启服务器监听程序就卡死,导致数据库无法使用必须重建监听程序,有什么好的优化方案?
回答 4
感觉得优先查看日志,看具体错误,目前看是监听方面存在问题,但数据应该不会影响;建议做好数据备份,在业务高峰期生成awr根据具体sql进行优化,大部分通过添加索引能提升数据库性能;深层优化就得以上老师说
19c rac 节点与DB节点不符合
回答 1
可能性1、创建数据库时,addinstance的时候,节点名称和实例名称反了;可能性2、数据库安装的时候模式选择错误,db安装Oracle支持策略或者池的概念,数据库实例可以在不同的RAC节点,需要铲
oracle大表删除索引
回答 3
我一般是alterindexindexnameinvisible;dropindexindexname;invisible后可能需要一些时间才能避免SQL继续使用该索引。
Oracle以一种什么样的方式处理临时文件?
回答 1
已采纳
一般而言,数据的每一个修改都会存储在重做日志,这些事务日志会在以后的某个时间重新应用以“重做事务”,例如,数据库实例失败后进行恢复时就可能需要“重做事务”。临时文件(temporaryfile是一种特
oracle 使用 rman 备份, 备份信息是记录到控制文件 ,现在控制文件 900M,有什么办法可以对控制文件瘦身?
回答 2
定期做清理吧,一般保留策略都是7天
oracle11g rac 进程asm_rbla 负载比较高
回答 1
不用处理,本来Oracle内存就是独占的,例如自己64G分配给Oracle用50G这50G不管oracle现在使用不适用都是独占的不能给别人用,所以没有问题。
windows下,执行 drop tablespace ABA including contents and datafiles; 但物理文件还在,手动删除提示oracle占用, 怎么办?
回答 4
已采纳
检查下数据文件是不是你删除表空间的数据文件,在检查下数据文件在数据库中的状态,查dbadatafiles
表空间碎片清理
回答 1
表空间清理:删除对象(清空回收站)MOVE对象到其他表空间整理对象碎片(move或者shrink)