需要当心的WHERE子句某些SELECT 语句中的WHERE子句不使用索引 这里有一些例子
在下面的例子里 != 将不使用索引 记住 索引只能告诉你什么存在于表中 而不能告诉你什么不存在于表中
不使用索引
SELECTACCOUNT_NAME
FROMTRANSACTION
WHEREAMOUNT!=;
使用索引
SELECTACCOUNT_NAME
FROMTRANSACTION
WHEREAMOUNT>;
下面的例子中 ||是字符连接函数 就象其他函数那样 停用了索引
不使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREACCOUNT_NAME||ACCOUNT_TYPE=AMEXA;
使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREACCOUNT_NAME=AMEXANDACCOUNT_TYPE=A;
下面的例子中 +是数学函数 就象其他数学函数那样 停用了索引
不使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREAMOUNT+>;
使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREAMOUNT>;
下面的例子中相同的索引列不能互相比较这将会启用全表扫描
不使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREACCOUNT_NAME=NVL(ACC_NAMEACCOUNT_NAME);
使用索引
SELECTACCOUNT_NAMEAMOUNT
FROMTRANSACTION
WHEREACCOUNT_NAMELIKENVL(ACC_NAME%);
如果一定要对使用函数的列启用索引 ORACLE新的功能 基于函数的索引(FunctionBased Index) 也许是一个较好的方案
CREATEINDEXEMP_IONEMP(UPPER(ename));/*建立基于函数的索引*/
SELECT*FROMempWHEREUPPER(ename)=BLACKSNAIL;/*将使用索引*/
连接多个扫描
如果你对一个列和一组有限的值进行比较 优化器可能执行多次扫描并对结果进行合并连接
举例
SELECT*
FROMLODGING
WHEREMANAGERIN(BILLGATESKENMULLER);
优化器可能将它转换成以下形式
SELECT*
FROMLODGING
WHEREMANAGER=BILLGATESORMANAGER=KENMULLER;
当选择执行路径时 优化器可能对每个条件采用LODGING$MANAGER上的索引范围扫描 返回的ROWID用来访问LODGING表的记录 (通过TABLE ACCESS BY ROWID 的方式) 最后两组记录以连接(CONCATENATION)的形式被组合成一个单一的集合
Explain Plan
SELECTSTATEMENTOptimizer=CHOOSE
CONCATENATION
TABLEACCESS(BYINDEXROWID)OFLODGING
INDEX(RANGESCAN)OFLODGING$MANAGER(NONUNIQUE)
TABLEACCESS(BYINDEXROWID)OFLODGING
INDEX(RANGESCAN)OFLODGING$MANAGER(NONUNIQUE)
本节和第节似乎有矛盾之处
CBO下使用更具选择性的索引
基于成本的优化器(CBO CostBased Optimizer)对索引的选择性进行判断来决定索引的使用是否能提高效率
如果索引有很高的选择性 那就是说对于每个不重复的索引键值只对应数量很少的记录
比如 表中共有条记录而其中有个不重复的索引键值 这个索引的选择性就是/ = 选择性越高 通过索引键值检索出的记录就越少
如果索引的选择性很低 检索数据就需要大量的索引范围查询操作和ROWID 访问表的操作 也许会比全表扫描的效率更低
下列经验请参阅
a 如果检索数据量超过%的表中记录数使用索引将没有显着的效率提高
b 在特定情况下 使用索引也许会比全表扫描慢 但这是同一个数量级上的区别 而通常情况下使用索引比全表扫描要快几倍乃至几千倍!
避免使用耗费资源的操作
带有DISTINCTUNIONMINUSINTERSECTORDER 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也是可以考虑的 毕竟它们的可读性很强
优化GROUP BY
提高GROUP BY 语句的效率 可以通过将不需要的记录在GROUP BY 之前过滤掉下面两个查询返回相同结果但第二个明显就快了许多
低效
SELECTJOBAVG(SAL)
FROMEMP
GROUPbyJOB
HAVINGJOB=PRESIDENT
ORJOB=MANAGER
高效
SELECTJOBAVG(SAL)
FROMEMP
WHEREJOB=PRESIDENT
ORJOB=MANAGERGROUPbyJOB
使用日期当
使用日期是需要注意如果有超过位小数加到日期上 这个日期会进到下一天!
例如
SELECTTO_DATE(JAN+)
FROMDUAL;
ReturnsJAN
SELECTTO_DATE(JAN+)
FROMDUAL;
ReturnsJAN
虽然本节和SQL性能优化没有关系 但是作者的功力可见一斑
使用显式的游标(CURSORs)
使用隐式的游标将会执行两次操作 第一次检索记录 第二次检查TOO MANY ROWS 这个exception 而显式游标不执行第二次操作
优化EXPORT和IMPORT
使用较大的BUFFER(比如MB )可以提高EXPORT和IMPORT的速度
ORACLE将尽可能地获取你所指定的内存大小即使在内存不满足也不会报错这个值至少要和表中最大的列相当否则列值会被截断
可以肯定的是 增加BUFFER会大大提高EXPORT IMPORT的效率 (曾经碰到过一个CASE 增加BUFFER后IMPORT/EXPORT快了倍!)
作者可能犯了一个错误 这个值至少要和表中最大的列相当否则列值会被截断 其中最大的列也许是指最大的记录大小
关于EXPORT/IMPORT的优化CSDN论坛中有一些总结性的贴子比如关于BUFFER参数 COMMIT参数等等 详情请查
分离表和索引
总是将你的表和索引建立在不同的表空间内(TABLESPACES) 决不要将不属于ORACLE内部系统的对象存放到SYSTEM表空间里 同时确保数据表空间和索引表空间置于不同的硬盘上
同时确保数据表空间和索引表空间置与不同的硬盘上可能改为如下更为准确 同时确保数据表空间和索引表空间置与不同的硬盘控制卡控制的硬盘上
