Oracle语句优化规则汇总(10)

更新时间:2023-03-28 14:04:01 阅读量: 生活好文 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

oracle sql 优化

语句优化规则汇总(10) 转:Oracle 语句优化规则汇总(10)(2010-10-15 10:42:45)转载标签:oracle分类: 数据库优化 it1. 需要当心的 WHERE 子句 某些 SELECT 语句中的 WHERE 子句不使用索引。 这里有一些例子。 在下面的例子里, ‘!=’ 将不使用索引。 记住, 索引只能告诉你什么存 在于表中, 而不能告诉你什么不存在于表中。 不使用索引: 不使用索引:SELECT ACCOUNT_NAME FROM TRANSACTION WHERE AMOUNT !=0;使用索引: 使用索引:SELECT ACCOUNT_NAME FROM TRANSACTION WHERE AMOUNT >0;下面的例子中, ‘||’是字符连接函数。 就象其他函数那样, 停用了索 引。

oracle sql 优化

不使用索引: 不使用索引:SELECT ACCOUNT_NAME,AMOUNT FROM TRANSACTION WHERE ACCOUNT_NAME||ACCOUNT_TYPE=‘AMEXA’;使用索引: 使用索引:SELECT ACCOUNT_NAME,AMOUNT FROM TRANSACTION WHERE ACCOUNT_NAME = ‘AMEX’AND ACCOUNT_TYPE=‘ A’;下面的例子中, ‘+’是数学函数。 就象其他数学函数那样, 停用了索引。 不使用索引: 不使用索引:SELECT ACCOUNT_NAME, AMOUNT FROM TRANSACTION WHERE AMOUNT + 3000 >5000;使用索引: 使用索引:SELECT ACCOUNT_NAME, AMOUNT FROM TRANSACTION WHERE AMOUNT > 2000 ;下面的例子中,相同的索引列不能互相比较,这将会启用全表扫描。

oracle sql 优化

不使用索引: 不使用索引:SELECT ACCOUNT_NAME, AMOUNT FROM TRANSACTION WHERE ACCOUNT_NAME = NVL(:ACC_NAME,ACCOUNT_NAME);使用索引: 使用索引:SELECT ACCOUNT_NAME, AMOUNT FROM TRANSACTION WHERE ACCOUNT_NAME LIKE NVL(:ACC_NAME,‘%’);:如果一定要对使用函数的列启用索引, ORACLE 新的功能: 基于函数的 索引(Function-Based Index) 也许是一个较好的方案。CREATE INDEX EMP_I ON EMP (UPPER(ename)); SELECT * FROM emp WHERE UPPER(ename) = ‘BLACKSNAIL’;2. 连接多个扫描 如果你对一个列和一组有限的值进行比较, 优化器可能执行多次扫描并对 结果进行合并连接。 举例: 举例:SELECT * FROM LODGING WHERE MANAGER IN (‘BILL GATES’,‘KEN MULLER’);

oracle sql 优化

优化器可能将它转换成以下形式 SELECT * FROM LODGING WHERE MANAGER = ‘BILL GATES’OR MANAGER = ‘KEN MULLER’; 当选择执行路径时, 优化器可能对每个条件采用 LODGING$MANAGER 上的索 引范围扫描。 返回的 ROWID 用来访问 LODGING 表的记录 (通过 TABLE ACCESS BY ROWID 的方式)。 最后两组记录以连接(CONCATENATION)的形式被组合成一个单 一的集合。 Explain Plan :SELECT STATEMENT Optimizer=CHOOSE CONCATENATION TABLE ACCESS (BY INDEX ROWID) OF LODGING INDEX (RANGE SCAN ) OF LODGING$MANAGER (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF LODGING INDEX (RANGE SCAN ) OF LODGING$MANAGER (NON-UNIQUE):本节和第 37 节似乎有矛盾之处。 3. CBO 下使用更具选择性的索引 基于成本的优化器(CBO, Cost-Based Optimizer)对索引的选择性进行判断 来决定索引的使用是否能提高效率。 如果索引有很高的选择性, 那就是说对于每个不重复的索引键值,只对应 数量很少的记录。 比如, 表中共有 100 条记录而其中有 80 个不重复的索引键值。 这个索引 的选择性就是 80/100 = 0.8 . 选择性越高, 通过索引键值检索出的记录就越 少。 如果索引的选择性很低, 检索数据就需要大量的索引范围查询操作和 ROWID 访问表的操作。 也许会比全表扫描的效率更低。 :下列经验请参阅:

oracle sql 优化

a. 如果检索数据量超过 30%的表中记录数。使用索引将没有显著的效率提 高。 b. 在特定情况下, 使用索引也许会比全表扫描慢, 但这是同一个数量级 上的区别。 而通常情况下,使用索引比全表扫描要快几倍乃至几千倍! 4. 避免使用耗费资源的操作 带有 DISTINCT,UNION,MINUS,INTERSECT,ORDER BY 的 SQL 语句会启动 SQL 引擎执行耗费资源的排序(SORT)功能。 DISTINCT 需要一次排序操作, 而其 他的至少需要执行两次排序。 例如,一个 UNION 查询,其中每个查询都带有 GROUP BY 子句, GROUP BY 会触发嵌入排序(NESTED SORT) ; 这样, 每个查询需要执行一次排序, 然后在 执行 UNION 时, 又一个唯一排序(SORT UNIQUE)操作被执行而且它只能在前面的 嵌入排序结束后才能开始执行。 嵌入的排序的深度会大大影响查询的效率。 通常, 带有 UNION, MINUS , INTERSECT 的 SQL 语句都可以用其他方式重写。 :如果你的数据库的 SORT_AREA_SIZE 调配得好, 使用 UNION , MINUS, INTERSECT 也是可以考虑的, 毕竟它们的可读性很强 5. 优化 GROUP BY 提高 GROUP BY 语句的效率, 可以通过将不需要的记录在 GROUP BY 之前过 滤掉。下面两个查询返回相同结果但第二个明显就快了许多。 低效: 低效:SELECT JOB , AVG(SAL) FROM EMP GROUP by JOB HAVING JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’高效: 高效:SELECT JOB , AVG(SAL)

oracle sql 优化

FROM EMP WHERE JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’GROUP by JOB6. 使用日期当 使用日期是,需要注意如果有超过 5 位小数加到日期上, 这个日期会进到 下一天! 例如: 1.SELECT TO_DATE(‘01-JAN-93’+.99999) FROM DUAL; Returns:“01-JAN-93 23:59:59‘2.SELECT TO_DATE(’01-JAN-93‘+.999999) FROM DUAL; Returns:“02-JAN-93 00:00:00‘:虽然本节和 SQL 性能优化没有关系, 但是作者的功力可见一斑。 使用显式的游标(CURSORs) 7. 使用显式的游标(CURSORs) 使用隐式的游标,将会执行两次操作。 第一次检索记录, 第二次检查 TOO MANY ROWS 这个 exception . 而显式游标不执行第二次操作。 8. 优化 EXPORT 和 IMPORT 使用较大的 BUFFER(比如 10MB , 10, 240, 000)可以提高 EXPORT 和 IMPORT 的速度。

oracle sql 优化

ORACLE 将尽可能地获取你所指定的内存大小,即使在内存不满足,也不会 报错。这个值至少要和表中最大的列相当,否则列值会被截断。 : 可以肯定的是, 增加 BUFFER 会大大提高 EXPORT , IMPORT 的效率。 (曾 经碰到过一个 CASE, 增加 BUFFER 后,IMPORT/EXPORT 快了 10 倍!) 作者可能犯了一个错误: “这个值至少要和表中最大的列相当,否则列值 会被截断。 ”其中最大的列也许是指最大的记录大小。 关于 EXPORT/IMPORT 的优化,CSDN 论坛中有一些总结性的贴子,比如关于 BUFFER 参数, COMMIT 参数等等, 详情请查。 9. 分离表和索引 总是将你的表和索引建立在不同的表空间内(TABLESPACES)。 决不要将不属 于 ORACLE 内部系统的对象存放到 SYSTEM 表空间里。 同时,确保数据表空间和 索引表空间置于不同的硬盘上。 :“同时,确保数据表空间和索引表空间置与不同的硬盘上。”可能改为如 下更为准确 “同时,确保数据表空间和索引表空间置与不同的硬盘控制卡控制 的硬盘上。”

本文来源:https://www.bwwdw.com/article/gk3n.html

Top