oracle全表扫描优化,优化Oracle with全表扫描的问题(二)

2024-02-16 06:40

本文主要是介绍oracle全表扫描优化,优化Oracle with全表扫描的问题(二),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://blog.itpub.net/29254281/viewspace-1242731/

尽信书不如无书

Oracle的优化器也不是万能的。

还是上次的SQL,开发说有时候执行时间超过3s。

我又查了查执行计划,发现有全表扫描和索引快速全扫描。这个是不符合预期的。

抽象问题如下:

create tableempas select * fromhr.employees;

create indexinx_hire_dateonemp(hire_date);

create indexinx_emp_idonemp(employee_id);

create indexinx_mgr_idonemp(manager_id);

查询主管号码为108的最近入职的3个雇员,并按照入职时间倒序排序,

SELECTt2.*

FROM (

SELECTrid

FROM (

SELECTemp.rowid ASrid,emp.employee_idASuser_id

FROMemp, (

SELECTemployee_id

FROMemp

WHEREmanager_id=108

)t

WHEREt.employee_id=emp.employee_id

ORDER BYhire_dateDESC

)

WHERE rownum <3

)t1,emp t2

WHEREt1.rid=t2.rowid

ORDER BYt2.hire_dateDESC;

b9433465ae2789f706ea02ba898860ed.png

全表扫描,哈希连接

使用Hint指定连接方式

SELECT /*+use_nl(t1,t2)*/t2.*

FROM (

SELECTrid

FROM (

SELECT /*+use_nl(t,emp)*/emp.rowid ASrid,emp.employee_idASuser_id

FROMemp, (

SELECTemployee_id

FROMemp

WHEREmanager_id=108

)t

WHEREt.employee_id=emp.employee_id

ORDER BYhire_dateDESC

)

WHERE rownum <3

)t1,emp t2

WHEREt1.rid=t2.rowid

ORDER BYt2.hire_dateDESC;

4bcfa21801a05b6520f0fffc3fff3d69.png

看来这个不是with的问题,而是优化器对于复杂的SQL不能正确的选择路径。

将原来的SQL修改如下,一致性读降为1000左右。

WITH t1

AS (SELECT to_userid

FROM friend_list f

WHERE f.userid = 411602438),

t2

AS (SELECT 'fc' AS t, rid, operTime

FROM (  SELECT/*+use_nl(t1,mc)*/

mc.ROWID rid, mc.operTime

FROM music_cover mc, t1

WHERE     mc.userid = t1.to_userid

AND mc.opus_stat > 0

AND operTime IS NOT NULL

AND SYNC_FLAG = 1

ORDER BY mc.operTime DESC)

WHERE ROWNUM < 50

UNION ALL

SELECT 'yc', rid, operTime

FROM (  SELECT/*+use_nl(t1,mo)*/

mo.ROWID rid, mo.operTime

FROM music_original mo, t1

WHERE     mo.userid = t1.to_userid

AND mo.opus_stat > 0

AND operTime IS NOT NULL

AND SYNC_FLAG = 1

ORDER BY mo.operTime DESC)

WHERE ROWNUM < 50

UNION ALL

SELECT 'sp', rid, operTime

FROM (  SELECT/*+use_nl(t1,mv)*/

mv.ROWID rid, mv.operTime

FROM music_video mv, t1

WHERE     mv.userid = t1.to_userid

AND mv.opus_stat > 0

AND operTime IS NOT NULL

AND SYNC_FLAG = 1

ORDER BY mv.operTime DESC)

WHERE ROWNUM < 50

UNION ALL

SELECT 'bz', rid, operTime

FROM (  SELECT/*+use_nl(t1,ma)*/

ma.ROWID rid, ma.operTime

FROM music_accompany ma, t1

WHERE     ma.userid = t1.to_userid

AND ma.opus_stat > 0

AND operTime IS NOT NULL

AND SYNC_FLAG = 1

ORDER BY ma.operTime DESC)

WHERE ROWNUM < 50

UNION ALL

SELECT 'rz', rid, operTime

FROM (  SELECT/*+use_nl(t1,bl)*/

bl.ROWID rid, bl.operTime

FROM blog_list bl, t1

WHERE     bl.userid = t1.to_userid

AND bl.opus_stat > 0

AND operTime IS NOT NULL

ORDER BY bl.operTime DESC)

WHERE ROWNUM < 50

UNION ALL

SELECT 'xc', rid, operTime

FROM (  SELECT/*+use_nl(t1,pl)*/

pl.ROWID rid, pl.operTime

FROM photo_list pl, t1

WHERE     pl.userid = t1.to_userid

AND pl.opus_stat > 0

AND operTime IS NOT NULL

ORDER BY pl.operTime DESC)

WHERE ROWNUM < 50),

t3

AS (SELECT *

FROM (SELECT TT.*, ROWNUM RN

FROM (  SELECT *

FROM t2

ORDER BY operTime DESC) TT

WHERE ROWNUM < 50)

WHERE RN >= 0),

t4

AS (SELECT/*+use_nl(t3,mc,ma,mo,mv,bl,pl)*/

t3.t opusType,

DECODE (t3.t,

'fc', 2,

'yc', 2,

'sp', 2,

'bz', 2,

'xc', 4,

'rz', 5)

type_code,

mc.userid

|| mo.userid

|| mv.userid

|| ma.userid

|| bl.userid

|| pl.userid

userId,

mc.file_url

|| mo.file_url

|| mv.file_url

|| ma.file_url

|| bl.file_url

|| pl.file_url

fileUrl,

mc.opus_Name

|| mo.opus_Name

|| mv.opus_name

|| ma.opus_name

|| bl.opus_name

|| pl.opus_name

opusName,

mc.opus_id

|| mo.opus_id

|| mv.opus_id

|| ma.opus_id

|| bl.opus_id

|| pl.opus_id

opusId,

TO_DATE (

TO_CHAR (mc.operTime, 'yyyy-mm-dd HH24:mi:ss')

|| TO_CHAR (mo.operTime, 'yyyy-mm-dd HH24:mi:ss')

|| TO_CHAR (mv.operTime, 'yyyy-mm-dd HH24:mi:ss')

|| TO_CHAR (ma.operTime, 'yyyy-mm-dd HH24:mi:ss')

|| TO_CHAR (bl.operTime, 'yyyy-mm-dd HH24:mi:ss')

|| TO_CHAR (pl.operTime, 'yyyy-mm-dd HH24:mi:ss'),

'yyyy-mm-dd HH24:mi:ss')

operTime,

mv.opus_desc

|| mo.opus_desc

|| mc.opus_desc

|| ma.opus_desc

|| bl.opus_desc

|| pl.opus_desc

opusDesc,

mv.album_id

|| mo.album_id

|| mc.album_id

|| ma.album_id

|| bl.album_id

|| pl.album_id

albumId,

mv.visit_num

|| mo.visit_num

|| mc.visit_num

|| ma.visit_num

|| bl.visit_num

|| pl.visit_num

visitNum

FROM t3

LEFT JOIN music_cover mc ON (t3.rid = mc.ROWID)

LEFT JOIN music_accompany ma ON (t3.rid = ma.ROWID)

LEFT JOIN music_original mo ON (t3.rid = mo.ROWID)

LEFT JOIN music_video mv ON (t3.rid = mv.ROWID)

LEFT JOIN blog_list bl ON (t3.rid = bl.ROWID)

LEFT JOIN photo_list pl ON (t3.rid = pl.ROWID))

SELECT/*+ ordered use_nl(t4,base) */

base.nickname,

base.showing,

DECODE (t4.type_code,

2, (SELECT al.album_name

FROM music_album al

WHERE al.album_id = t4.albumId),

4, (SELECT al.album_name

FROM photo_album al

WHERE al.album_id = t4.albumId),

5, (SELECT al.album_name

FROM blog_album al

WHERE al.album_id = t4.albumId))

albumName,

(SELECT COUNT (*)

FROM user_comment com

WHERE     com.typeid = t4.type_code

AND t4.opusId = com.to_id

AND status >= 0)

commentTotal,

t4.*

FROM t4, mvbox_user.user_baseinfo base

WHERE base.userid = t4.userId

ORDER BY t4.operTime DESC;

这篇关于oracle全表扫描优化,优化Oracle with全表扫描的问题(二)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/713791

相关文章

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Redis出现中文乱码的问题及解决

《Redis出现中文乱码的问题及解决》:本文主要介绍Redis出现中文乱码的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 问题的产生2China编程. 问题的解决redihttp://www.chinasem.cns数据进制问题的解决中文乱码问题解决总结

MyBatisPlus如何优化千万级数据的CRUD

《MyBatisPlus如何优化千万级数据的CRUD》最近负责的一个项目,数据库表量级破千万,每次执行CRUD都像走钢丝,稍有不慎就引起数据库报警,本文就结合这个项目的实战经验,聊聊MyBatisPl... 目录背景一、MyBATis Plus 简介二、千万级数据的挑战三、优化 CRUD 的关键策略1. 查

全面解析MySQL索引长度限制问题与解决方案

《全面解析MySQL索引长度限制问题与解决方案》MySQL对索引长度设限是为了保持高效的数据检索性能,这个限制不是MySQL的缺陷,而是数据库设计中的权衡结果,下面我们就来看看如何解决这一问题吧... 目录引言:为什么会有索引键长度问题?一、问题根源深度解析mysql索引长度限制原理实际场景示例二、五大解决

Springboot如何正确使用AOP问题

《Springboot如何正确使用AOP问题》:本文主要介绍Springboot如何正确使用AOP问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录​一、AOP概念二、切点表达式​execution表达式案例三、AOP通知四、springboot中使用AOP导出

Python中Tensorflow无法调用GPU问题的解决方法

《Python中Tensorflow无法调用GPU问题的解决方法》文章详解如何解决TensorFlow在Windows无法识别GPU的问题,需降级至2.10版本,安装匹配CUDA11.2和cuDNN... 当用以下代码查看GPU数量时,gpuspython返回的是一个空列表,说明tensorflow没有找到

解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题

《解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘问题》:本文主要介绍解决未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4... 目录未解析的依赖项:‘net.sf.json-lib:json-lib:jar:2.4‘打开pom.XM

IDEA Maven提示:未解析的依赖项的问题及解决

《IDEAMaven提示:未解析的依赖项的问题及解决》:本文主要介绍IDEAMaven提示:未解析的依赖项的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录IDEA Maven提示:未解析的依编程赖项例如总结IDEA Maven提示:未解析的依赖项例如

Redis分片集群、数据读写规则问题小结

《Redis分片集群、数据读写规则问题小结》本文介绍了Redis分片集群的原理,通过数据分片和哈希槽机制解决单机内存限制与写瓶颈问题,实现分布式存储和高并发处理,但存在通信开销大、维护复杂及对事务支持... 目录一、分片集群解android决的问题二、分片集群图解 分片集群特征如何解决的上述问题?(与哨兵模