oracle SQL性能优化
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
COMMIT 所释放的资源 :
a. 回滚段上用于恢复数据的信息 .
b. 被程序语句获得的锁
c. redo log buffer 中的空间
d. ORACLE 为管理上述 3 种资源中的内部花费
ROUND ((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2 ) Hit_radio,
ROUND (DISK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
FROM V$SQLAREA
WHERE EXECUTIONS>0
AND BUFFER_GETS > 0
AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8
ORDER BY 4 DESC ;
SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
( 高效 ):
SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X'
FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO ) ;
WHERE 子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．
举例 :
低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效 :
SELECT … FROM DEPT WHERE SAL > 25000/12;
SELECT * FROM EMP WHERE DEPTNO >=4
低效 :
SELECT * FROM EMP WHERE DEPTNO >3
两者的区别在于 , 前者 DBMS 将直接跳到第一个 DEPT 等于 4 的记录而后者将首先定位到 DEPTNO=3 的记录并且向前扫描到第一个 DEPT 大于 3 的记录 .
高效 :
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10
UNION
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE REGION = “MELBOURNE”
低效 :
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10 OR REGION = “MELBOURNE”
如果你坚持要用 OR, 那就需要返回记录最少的索引列写在最前面 .
SELECT …. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
高效
SELECT … FROM LOCATION WHERE LOC_IN IN (10,20,30);
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL ;
高效 : ( 索引有效 )
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >= 0;
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
UNION
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
高效 :
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
UNION ALL
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
ORDER BY 中所有的列必须包含在相同的索引中并保持在索引中的排列顺序 .
ORDER BY 中所有的列必须定义为非空 .
WHERE 子句使用的索引和 ORDER BY 子句中所使用的索引不能并列 .
表 DEPT 包含以下列 :
DEPT_CODE PK NOT NULL
DEPT_DESC NOT NULL
DEPT_TYPE NULL
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE
高效 : ( 使用索引 )
SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0
SELECT … FROM EMP WHERE EMPNO = ‘123'
实际上 , 经过 ORACLE 类型转换 , 语句转化为 :
SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123')
幸运的是 , 类型转换没有发生在索引列上 , 索引的用途没有被改变 .
现在 , 假设 EMP_TYPE 是一个字符类型的索引列 .
SELECT … FROM EMP WHERE EMP_TYPE = 123
这个语句被 ORACLE 转换为 :
SELECT … FROM EMP WHERE TO_NUMBER(EMP_TYPE)=123
因为内部发生的类型转换 , 这个索引将不会被用到 ! 为了避免 ORACLE 对你的 SQL 进行隐式的类型转换 , 最好把类型转换用显式表现出来 . 注意当字符和数值比较时 , ORACLE 会优先转换数值类型到字符类型
在下面的例子里 , (1) ‘!=' 将不使用索引 . 记住 , 索引只能告诉你什么存在于表中 , 而不能告诉你什么不存在于表中 . (2) ‘||' 是 字符连接函数 . 就象其他函数那样 , 停用了索引 . (3) ‘+' 是数学函数 . 就象其他数学函数那样 , 停用了索引 . (4) 相同的索引列不能互相比较 , 这将会启用全表扫描 .
b. 在特定情况下 , 使用索引也许会比全表扫描慢 , 但这是同一个数量级上的区别 . 而通常情况下 , 使用索引比全表扫描要块几倍乃至几千倍 !
执行耗费资源的排序 (SORT) 功能 . DISTINCT 需要一次排序操作 , 而其他的至少需要执行两次排序 . 通常 , 带有 UNION, MINUS , INTERSECT 的 SQL 语句都可以用其他方式重写 . 如果你的数据库的 SORT_AREA_SIZE 调配得好 , 使用 UNION , MINUS, INTERSECT 也是可以考虑的 , 毕竟它们的可读性很强
SELECT JOB , AVG(SAL)
FROM EMP
GROUP JOB
HAVING JOB = ‘PRESIDENT'
OR JOB = ‘MANAGER'
高效 :
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = ‘PRESIDENT'
OR JOB = ‘MANAGER'
GROUP JOB
优化数据库的思想及SQL语句优化的原则
优化数据库的思想：
================
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。（可以用Sybase的SQL Expert，可惜我没找到unexpired的
序列号）
5、清理删除日志。
SQL语句优化的原则：
==================
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引
下，数据在物理上随机存放在数据页上。合理的索引设计要建立在
对各种查询的分析和预测上。一般来说：①.有大量重复值、且经常有范围查询
（between, > ,< ，> =,< =）和order by、group by发生的列，可考
虑建立群集索引；②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引
；③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定
是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索
引会导致系统低效。用户在表中每加进一个索引，维护索引集
合就要做相应的更新工作。
2、IS NULL 与 IS NOT NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有
多列这样的情况下，只要这些列中有一列含有null，该列就会从
索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何
在where子句中使用is null或is not null的语句优化器是不允
许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所
有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽量少用格式转换。
5、当在SQL SERVER 2000中，如果存储过程只有一个参数，并且是OUTPUT类型的，必
须在调用这个存储过程的时候给这个参数一个初始的值，否则
会出现调用错误。
6、ORDER BY和GROPU BY
使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。注意
如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时
要尽可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把
子句拆开。拆开的子句中应该包含索引。
9、SET SHOWPLAN_ALL ON 查看执行方案。DBCC检查数据库数据完整性。
DBCC(DataBase Consistency Checker）是一组用于验证 SQL Server 数据
库完整性的程序。
10、慎用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临
时表定义游标进行操作，这样可使性能得到明显提高。
总结：所谓优化即WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经
验显示，SQL Server性能的最大改进得益于逻辑的数据库设计、
索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中
的不足引起的。其实SQL优化的实质就是在结果正确的前提下，
用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索
的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是
在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制
以及操作系统层的总体设计。
影响SQL server性能的关键
1 逻辑数据库和表的设计
数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。
标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化表的一些好处。
A:由于表窄，因此可以使排序和建立索引更为迅速
B:由于多表，所以多镞的索引成为可能
C:更窄更紧凑的索引
D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引多的情况下会对系统性能产生很大的影响
E:更少的空值和更少的多余值，增加了数据库的紧凑性由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。
定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。
2 索引的设计
A:尽量避免表扫描
检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。
下面的两个条件可以提高索引的优化查询性能！
第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列
避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能
例如：下面的例子用了pubs数据库。
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
按下面几个列上建立的索引将会是对优化器有用的索引
?au_lname
?au_lname, au_fname
而在下面几个列上建立的索引将不会对优化器起到好的作用
?au_address
?au_fname, au_lname
考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上
将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。
对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的
histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。
有用的索引会提高select语句的性能，包括insert,uodate,delete。
但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。
在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。
select count(distinct cloumn_name) from table_name
假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。
Unique values Index
5000 Nonclustered index
20 Clustered index
3 No index
镞索引和非镞索引的选择
<1:>镞索引是行的物理顺序和索引的顺序是一致的。页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。在至少有一个索引的表中，你应该有一个镞索引。
在下面的几个情况下，你可以考虑用镞索引：
例如： 某列包括的不同值的个数是有限的（但是不是极少的）
顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。
例如： 对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行操作的列上。
select * from sales where ord_date between ’5/1/93’ and ’6/1/93’
例如： 对查询时返回大量结果的列可以使用镞索引。
SELECT * FROM phonebook WHERE last_name = ’Smith’
当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。
当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。
一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。
<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。
在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。
在有很多不同值的列上可以考虑使用非镞索引
例如：一个part_id列在一个part表中
select * from employee where emp_id = ’pcm9809f’
查询语句中用order by 子句的列上可以考虑使用镞索引
3 查询语句的设计
SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。
在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。
例如下面的例子，
select qty from sales where stor_id=7131
是很有效的比下面这个无限制的查询
select qty from sales
避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。
这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。
第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。
这时多索引是没有用的。
For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in
the pubs database,
下面这个query语句利用了au_lname上的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
AND au_fname = ’Johnson’
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = ’Johnson’
扫一扫
2281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
