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

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传

购买磨轮平衡机时应该注意什么问题和技巧

在购买磨轮平衡机时,您应该注意以下几个关键点: 平衡精度 平衡精度是衡量平衡机性能的核心指标,直接影响到不平衡量的检测与校准的准确性,从而决定磨轮的振动和噪声水平。高精度的平衡机能显著减少振动和噪声,提高磨削加工的精度。 转速范围 宽广的转速范围意味着平衡机能够处理更多种类的磨轮,适应不同的工作条件和规格要求。 振动监测能力 振动监测能力是评估平衡机性能的重要因素。通过传感器实时监

MySQL高性能优化规范

前言:      笔者最近上班途中突然想丰富下自己的数据库优化技能。于是在查阅了多篇文章后,总结出了这篇! 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀,备份

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。 解决方案: 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内,大量缓存数据同时失效,导致所有请求直接涌向数据库,瞬间增加数据库的负载压力,可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者