转自:http://www.cnblogs.com/iliuyuet/p/4438147.html
在软件开发中,作为程序猿,少不了和数据库打交道,少不了增删该查,尤其是查询的效率问题,所以,今天我们讨论一下数据库的查询效率问题及各种优化方法
一.首先对于硬件及数据库配置方面来说,可以考虑以下几方面:
1、升级硬件
2、扩大服务器的内存
3、增加服务器CPU个数
4、对于大的数据库不要设置数据库自动增长,它会降低服务器的性能
二.软件方面,主要是sql优化方面
1、建立适当的索引(至于为什么请参考为什么建立了索引可以提高效率)
2、避免在索引列上使用计算
WHERE 子句中,如果索引列是函数的一部分.优化器将不使用索引而使用全表扫描.
举例 :
低效:
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效 :
SELECT … FROM DEPT WHERE SAL > 25000/12;
此时应建立基于函数的索引,例如:create index i_account_real_name on account(upper(real_name))
3、避免在索引列上使用 NOT
通常 ,我们要避免在索引列上使用 NOT, NOT 会产生和在索引列上使用函数相同的影响 . 当 ORACLE” 遇到 ”NOT, 他就会停止使用索引转而执行全表扫描 .
4、避免在索引列上使用 IS NULL 和 IS NOT NULL
避免在索引中使用任何可以为空的列, ORACLE 将无法使用该索引 .对于单列索引,如果列包含空值,索引中将不存在此记录 . 对于复合索引,如果每个列都为空,索引中同样不存在此记录 . 如果至少有一个列不为空,则记录存在于索引中,举例 : 如果唯一性索引建立在表的 A 列和 B 列上 , 并且表中存在一条记录的 A,B 值为(123,null) , ORACLE 将不接受下一条具有相同 A,B 值( 123,null )的记录 ( 插入 ). 然而如果所有的索引列都为空, ORACLE 将认为整个键值为空而空不等于空 . 因此你可以插入 1000 条具有相同键值的记录 , 当然它们都是空 ! 因为空值不存在于索引列中 , 所以 WHERE 子句中对索引列进行空值比较将使 ORACLE 停用该索引 .
低效 : ( 索引失效 )
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL ;
高效 : ( 索引有效 )
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >= 0;
5、避免返回不必要的行和列
在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。如果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重。
6、SELECT 子句中避免使用 ‘ * ‘
ORACLE 在解析的过程中 , 会将 '*' 依次转换成所有的列名 , 这个工作是通过查询数据字典完成的 , 这意味着将耗费更多的时间
7、在IN后面值的列表中,将出现最频繁的值放在最前面,出现得最少的放在最后面,减少判断的次数
8、使用batch处理
一次更新多条记录比分多次更新每次一条快,就是说批处理好
9、注意UNion和UNion all 的区别
UNION和UNION all均是对两个结果的取并集,但是union会对结果进行去重和排序,但是会牺牲性能,而union all 不会,所以若可以提前确认两个结果集中不会产生重复的内容,使用union all 最佳
10、WHERE 子句中的连接顺序
ORACLE 采用自下而上(自右向左)的顺序解析 WHERE 子句 , 根据这个原理 , 表之间的连接必须写在其他 WHERE 条件之前 , 那些可以过滤掉最大数量记录的条件必须写在 WHERE 子句的末尾
11、DISTINCT的使用
注意,在数据量大的时候,尽量不要使用,它同UNION一样会使查询变慢。因为Oracle需要对后面的所有字段进行排序,消耗性能
12、尽可能不使用光标,它占用大量的资源
13、将需要查询的结果预先计算好放在表中,查询的时候再SELECT
14、数据库有一个原则是代码离数据越近越好,所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小,编写程序质量高,并且执行的速度快。
15、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次,所以有时会慢些。
16、在必要是对全局或者局部临时表创建索引,有时能够提高速度,但不是一定会这样,因为索引也耗费大量的资源。它的创建同是实际表一样。
17、用OR的字句可以分解成多个查询,并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引,用UNION all执行的效率更高.多个OR的字句没有用到索引,改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
18、尽量少用视图,它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质:它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时,不要使用指向多个表的视图,直接从表检索或者仅仅包含这个表的视图上读,否则增加了不必要的开销,查询受到干扰.
19、尽量将数据的处理工作放在服务器上,减少网络的开销,如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的 SQL语句,是控制流语言的集合,速度当然快。
20、不要在一句话里再三的使用相同的函数,浪费资源,将结果放在变量里再调用更快
21、SELECT COUNT(*)的效率教低,尽量变通它的写法,而EXISTS快.同时请注意区别: select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的。
22、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的,则优化器对其进行优化为Convert(float,3000),因为3000是个整数,我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。
23、选择最有效率的表名顺序 ( 只在基于规则的优化器中有效 )
ORACLE 的解析器按照从右到左的顺序处理 FROM 子句中的表名, FROM 子句中写在最后的表 ( 基础表 driving table) 将被最先处理,在 FROM 子句中包含多个表的情况下 , 你必须选择记录条数最少的表作为基础表。如果有 3 个以上的表连接查询 , 那就需要选择交叉表 (intersection table) 作为基础表 , 交叉表是指那个被其他表所引用的表.
24、使用 DECODE 函数来减少处理时间
使用 DECODE 函数可以避免重复扫描相同记录或重复连接相同的表 .
25、用 TRUNCATE 替代 DELETE
当删除表中的记录时 , 在通常情况下 , 回滚段 (rollback segments ) 用来存放可以被恢复的信息 . 如果你没有 COMMIT 事务 ,ORACLE 会将数据恢复到删除之前的状态 ( 准确地说是恢复到执行删除命令之前的状况 ) 而当运用 TRUNCATE 时 , 回滚段不再存放任何可被恢复的信息 . 当命令运行后 , 数据不能被恢复 . 因此很少的资源被调用 , 执行时间也会很短
26、尽量多使用 COMMIT
只要有可能 , 在程序中尽量多使用 COMMIT, 这样程序的性能得到提高 , 需求也会因为 COMMIT 所释放的资源而减少 :
COMMIT 所释放的资源 :
a. 回滚段上用于恢复数据的信息 .
b. 被程序语句获得的锁
c. redo log buffer 中的空间
d. ORACLE 为管理上述 3 种资源中的内部花费
27、一般在GROUP BY 的HAVING字句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优:
select的Where字句选择所有合适的行,Group By用来分组个统计行,Having字句用来剔除多余的分组。这样Group By 个Having的开销小,查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算,只是分组,那么用Distinct更快
28、如果使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。 like 'a%' 使用索引 like '%a' ,不使用索引用 like '%a%' 查询时,查询耗时和字段值总长度成正比,所以不能用CHAR类型,而是VARCHAR。对于字段的值很长的建全文索引。
29、一般不要用如下的字句: "IS NULL", " <> ", "!=", "!> ", "! <", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'",因为他们不走索引全是表扫描。也不要在WHere字句中的列名加函数,如Convert,substring等,如果必须用函数的时候,创建计算列再创建索引来替代.还可以变通写法:WHERE SUBSTRING(firstname,1,1) = 'm'改为WHERE firstname like 'm%'(索引扫描),一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表,使用EXISTS、NOT EXISTS ,IN , LEFT OUTER JOIN 来替代,特别是左连接,而Exists比IN更快,最慢的是NOT操作.如果列的值含有空,以前它的索引不起作用,现在2000的优化器能够处理了。相同的是IS NULL,“NOT", "NOT EXISTS", "NOT IN"能优化她,而” <> ”等还是不能优化,用不到索引。
30、整合简单 , 无关联的数据库访问
如果你有几个简单的数据库查询语句 , 你可以把它们整合到一个查询中 ( 即使它们之间没有关系 )
31、删除重复记录
最高效的删除重复记录方法 ( 因为使用了 ROWID) 例子:DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
32、MIN() 和 MAX()能使用到合适的索引
33、用 Where 子句替换 HAVING 子句
避免使用 HAVING 子句 , HAVING 只会在检索出所有记录之后才对结果集进行过滤 . 这个处理需要排序 , 总计等操作 . 如果能通过 WHERE 子句限制记录的数目 , 那就能减少这方面的开销 .
34、 使用表的别名 (Alias)
当在 SQL 语句中连接多个表时 , 请使用表的别名并把别名前缀于每个 Column 上 . 这样一来 , 就可以减少解析的时间并减少那些由 Column 歧义引起的语法错误 .
35、 用 EXISTS 替代 I N 、 用 NOT EXISTS 替代 NOT IN
在许多基于基础表的查询中 , 为了满足一个条件 , 往往需要对另一个表进行联接 . 在这种情况下 , 使用 EXISTS( 或 NOT EXISTS) 通常将提高查询的效率 . 在子查询中 ,NOT IN 子句将执行一个内部的排序和合并 . 无论在哪种情况下 ,NOT IN 都是最低效的 ( 因为它对子查询中的表执行了一个全表遍历 ). 为了避免使用 NOT IN , 我们可以把它改写成外连接 (Outer Joins)或 NOT EXISTS.
例子:
( 高效 ) SELECT * FROM EMP ( 基础表 ) WHERE EMPNO > 0 AND EXISTS ( SELECT ‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB')
( 低效 ) SELECT * FROM EMP ( 基础表 ) WHERE EMPNO > 0 AND DEPTNO IN (SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB' )
36、用 EXISTS 替换 DISTINCT :
当提交一个包含一对多表信息 ( 比如部门表和雇员表 ) 的查询时 , 避免在 SELECT 子句中使用 DISTINCT. 一般可以考虑用 EXIST 替换 , EXISTS 使查询更为迅速 , 因为 RDBMS 核心模块将在 子查询的条件一旦满足后 , 立刻返回结果 . 例子:
( 低效 ): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO
( 高效 ): SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO ) ;
37、sql 语句用大写的 ;因为 oracle 总是先解析 sql 语句,把小写的字母转换成大写的再执行
38、在 java 代码中尽量少用连接符“+”连接字符串!
39、用 >= 替代 >
高效 : SELECT * FROM EMP WHERE DEPTNO >=4
低效 : SELECT * FROM EMP WHERE DEPTNO >3
两者的区别在于 , 前者 DBMS 将直接跳到第一个 DEPT 等于 4 的记录,而后者将首先定位到 DEPTNO=3 的记录并且向前扫描到第一个 DEPT 大于 3 的记录 .
40、用 UNION 替换 OR ( 适用于索引列 )
通常情况下 , 用 UNION 替换 WHERE 子句中的 OR 将会起到较好的效果 . 对索引列使用 OR 将造成全表扫描 . 注意 , 以上规则只针对多个索引列有效 . 如果有 column 没有被索引 , 查询效率可能会因为你没有选择 OR 而降低 . 在下面的例子中 , LOC_ID 和 REGION 上都建有索引 .
高效 : 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, 那就需要返回记录最少的索引列写在最前面 .
41、用 IN 来替换 OR
这是一条简单易记的规则,但是实际的执行效果还须检验,在 ORACLE8i 下,两者的执行路径似乎是相同的.
低效 :
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);
42、总是使用索引的第一个列
如果索引是建立在多个列上 , 只有在它的第一个列 (leading column) 被 where 子句引用时 , 优化器才会选择使用该索引 . 这也是一条简单而重要的规则,当仅引用索引的第二个列时 , 优化器使用了全表扫描而忽略了索引
43、用 WHERE 替代 ORDER BY
ORDER BY 子句只在两种严格的条件下使用索引 .
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
44、避免改变索引列的类型 .:
当比较不同数据类型的数据时 , ORACLE 自动对列进行简单的类型转换 .
假设 EMPNO 是一个数值类型的索引列 . 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 会优先转换数值类型到字符类型
45、需要当心的 WHERE 子句 :
某些 SELECT 语句中的 WHERE 子句不使用索引 . 这里有一些例子 .
在下面的例子里 ,
(1) ‘!=' 将不使用索引 . 记住 , 索引只能告诉你什么存在于表中 , 而不能告诉你什么不存在于表中 .
(2) ‘||' 是字符连接函数 . 就象其他函数那样 , 停用了索引 .
(3) ‘+' 是数学函数 . 就象其他数学函数那样 , 停用了索引 .
(4) 相同的索引列不能互相比较 , 这将会启用全表扫描 .
46、避免使用耗费资源的操作 :
带有 DISTINCT,UNION,MINUS,INTERSECT,ORDER BY 的 SQL 语句会启动 SQL 引擎 . 执行耗费资源的排序 (SORT) 功能 . DISTINCT 需要一次排序操作 , 而其他的至少需要执行两次排序 . 通常 , 带有 UNION, MINUS , INTERSECT 的 SQL 语句都可以用其他方式重写 . 如果你的数据库的 SORT_AREA_SIZE 调配得好 , 使用 UNION , MINUS, INTERSECT 也是可以考虑的 , 毕竟它们的可读性很强
47、优化 GROUP BY:
提高 GROUP BY 语句的效率 , 可以通过将不需要的记录在 GROUP BY 之前过滤掉 . 下面两个查询返回相同结果但第二个明显就快了许多 .
低效 :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
48、操作符优化
1)IN 操作符
用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格。
但是用IN的SQL性能总是比较低的,从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别:
ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了。
推荐方案:在业务密集的SQL当中尽量不采用IN操作符。
2)NOT IN操作符
此操作是强列推荐不使用的,因为它不能应用表的索引。
推荐方案:用NOT EXISTS 或(外连接+判断为空)方案代替
3)<> 操作符(不等于)
不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。
推荐方案:用其它相同功能的操作运算代替,如
a<>0 改为 a>0 or a<0
a<>’’ 改为 a>’’
4)IS NULL 或IS NOT NULL操作(判断字段是否为空)
判断字段是否为空一般是不会应用索引的,因为B树索引是不索引空值的。
推荐方案:
用其它相同功能的操作运算代替,如 a is not null 改为 a>0 或a>’’等。
5)不允许字段为空,而用一个缺省值代替空值,如业扩申请中状态字段不允许为空,缺省为申请。
6)建立位图索引(有分区的表不能建,位图索引比较难控制,如字段值太多索引会使性能下降,多人更新操作会增加数据块锁的现象)。
7)> 及 < 操作符(大于或小于操作符)
大于或小于操作符一般情况下是不用调整的,因为它有索引就会采用索引查找,但有的情况下可以对它进行优化,如一个表有100万记录,一个数值型字段A,30万记录的A=0,30万记录的A=1,39万记录的A=2,1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了,因为A>2时ORACLE会先找出为2的记录索引再进行比较,而A>=3时ORACLE则直接找到=3的记录索引。
8)LIKE操作符
LIKE操作符可以应用通配符查询,里面的通配符组合可能达到几乎是任意的查询,但是如果用得不好则会产生性能上的问题,如LIKE ‘%5400%’ 这种查询不会引用索引,而LIKE ‘X5400%’则会引用范围索引。一个实际例子:用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描,如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询,性能肯定大大提高。