没有合适的资源?快使用搜索试试~ 我知道了~
OracleSQL的优化.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
5星 · 超过95%的资源 1 下载量 197 浏览量
2023-05-17
13:20:26
上传
评论
收藏 1.49MB PDF 举报
温馨提示
试读
24页
OracleSQL的优化.pdf
资源推荐
资源详情
资源评论
. .
Oracle SQL 的优化
标签: oraclesql 优化 date 数据库 subquery
2009-10-14 21:18 18149 人阅读 评论(21) 收藏举报
分类:
Oracle Basic Knowledge〔208〕
SQL 的优化应该从 5 个方面进展调整:
1.去掉不必要的大型表的全表扫描
2.缓存小型表的全表扫描
3.检验优化索引的使用
4.检验优化的连接技术
5.尽可能减少执行方案的 Cost
SQL 语句:
是对数据库(数据)进展操作的惟一途径;
消耗了 70%~90%的数据库资源;独立于程序设计逻辑,相对于对程序源代码的
优化,对 SQL 语句的优化在时间本钱和风险上的代价都很低;
可以有不同的写法;易学,难精通。
SQL 优化:
固定的 SQL 书写习惯,一样的查询尽量保持一样,存储过程的效率较高。
应该编写与其格式一致的语句,包括字母的大小写、标点符号、换行的位置等都
要一致
ORACLE 优化器:
在任何可能的时候都会对表达式进展评估,并且把特定的语法构造转换成等价的
构造,这么做的原因是
. v .
. .
要么结果表达式能够比源表达式具有更快的速度
要么源表达式只是结果表达式的一个等价语义构造
不同的 SQL 构造有时具有同样的操作〔例如:
= ANY (subquery) and IN (subquery)〕,ORACLE 会把他们映射到一个单一的语义
构造。1 常量优化:
常量的计算是在语句被优化时一次性完成,而不是在每次执行时。下面是检索月
薪大于 2000 的的表达式:
sal > 24000/12
sal > 2000
sal*12 > 24000
如果 SQL 语句包括第一种情况,优化器会简单地把它转变成第二种。
优化器不会简化跨越比较符的表达式,例如第三条语句,鉴于此,应尽量写用常
量跟字段比较检索的表达式,而不要将字段置于表达式当中。否那么没有方法优
化,比方如果 sal 上有索引,第一和第二就可以使用,第三就难以使用。
2 操作符优化:
优化器把使用 LIKE 操作符和一个没有通配符的表达式组成的检索表达式转换为
一个"=〞操作符表达式。
例如:优化器会把表达式 ename LIKE 'SMITH'转换为 ename = 'SMITH'
优化器只能转换涉及到可变长数据类型的表达式,前一个例子中,如果 ENAME
字段的类型是 CHAR(10),那么优化器将不做任何转换。
一般来讲 LIKE 比较难以优化。
其中:
. v .
. .
~~IN 操作符优化: 优化器把使用 IN 比较符的检索表达式替换为等价的使用
"=〞和"OR〞操作符的检索表达式。
例如,优化器会把表达式 ename IN ('SMITH','KING','JONES')替换为
ename = 'SMITH' OR ename = 'KING' OR ename = 'JONES‘
oracle 会将 in 后面的东西生成一存中的临时表。然后进展查询。
如何编写高效的 SQL:
当然要考虑 sql 常量的优化和操作符的优化啦,另外,还需要:1 合理的索引
设计:例:表 record 有 620000 行,试看在不同的索引下,下面几个 SQL 的运行
情况:
语句 A
SELECT count(*) FROM record
WHERE date >'19991201' and date <'19991214‘ and amount >2000
语句 B
SELECT count(*) FROM record
WHERE date >'19990901' and place IN ('BJ','SH')
语句 C
SELECT date,sum(amount) FROM record
group by date
1 在 date 上建有一个非聚集索引
A:(25 秒)
B:(27 秒)
C:(55 秒)
. v .
. .
分析:
date 上有大量的重复值,在非聚集索引下,数据在物理上随机存放在数据页上,
在围查找时,必须执行一次表扫描才能找到这一围的全部行。
2 在 date 上的一个聚集索引
A:〔14 秒〕
B:〔14 秒〕
C:〔28 秒〕
分析:
在聚集索引下,数据在物理上按顺序在数据页上,重复值也排列在一起,因而在
围查找时,可以先找到这个围的起末点,且只在这个围扫描数据页,防止了大围
扫描,提高了查询速度。
3 在 place,date,amount 上的组合索引
A:〔26 秒〕
C:〔27 秒〕
B:〔<1 秒〕
分析:
这是一个不很合理的组合索引,因为它的前导列是 place,第一和第二条 SQL 没
有引用 place,因此也没有利用上索引;第三个 SQL 使用了 place,且引用的所有
列都包含在组合索引中,形成了索引覆盖,所以它的速度是非常快的。
4 在 date,place,amount 上的组合索引
A:(<1 秒)
B:〔<1 秒〕
. v .
. .
C:〔11 秒〕
分析:
这是一个合理的组合索引。它将 date 作为前导列,使每个 SQL 都可以利用索引,
并且在第一和第三个 SQL 中形成了索引覆盖,因而性能到达了最优。总结 1
缺省情况下建立的索引是非聚集索引,但有时它并不是最正确的;合理的索引设
计要建立在对各种查询的分析和预测上。一般来说:
有大量重复值、且经常有围查询〔between, >,<,>=,<=〕和 order by、group by
发生的列,考虑建立聚集索引;
经 常同时存取多列,且每列都含有重复值可考虑建立组合索引;在条件表达式
中经常用到的不同值较多的列上建立检索,在不同值少的列上不要建立索引。比
方在雇员 表的"性别〞列上只有"男〞与"女〞两个不同值,因此就无必要建立索
引。如果建立索引不但不会提高查询效率,反而会严重降低更新速度。
组合索引要尽量使关键查询形成索引覆盖,其前导列一定是使用最频繁的列。
2 防止使用不兼容的数据类型:
例如 float 和 INt、char 和 varchar、bINary 和 varbINary 是不兼容的。数据类型的
不兼容可能使优化器无法执行一些本来可以进展的优化操作。例如:
SELECT name FROM employee WHERE salary >60000
在这条语句中,如 salary 字段是 money 型的,那么优化器很难对其进展优化,因为
60000 是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时
转化。3 IS NULL 与 IS NOT NULL:不 能用 null 作索引,任何包含 null 值的列
都将不会被包含在索引中。即使索引有多列这样的情况下,只要这些列中有一列
含有 null,该列就会从索引中排除。也就是说如果某列存在空值,即使对该列建
. v .
剩余23页未读,继续阅读
资源评论
- qq_266975732024-04-11感谢资源主的分享,很值得参考学习,资源价值较高,支持!
hhappy0123456789
- 粉丝: 59
- 资源: 5万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功