数据库增删改查的效率优化

个人总结:
1.尽量减少sql语句调用的次数,避免在循环语句中执行数据库操作.
2.尽量减少多表的联查,用空间换时间,跟业务逻辑紧密绑定.
3.适当增加插入工作量,提高查询效率.根据接口的访问频率调整表结构
4.多使用联合主键和复合主键
5.分页返回查询结果,限制每次查询数量
别人的经验:
一.首先对于硬件及数据库配置方面来说,可以考虑以下几方面:

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的索引进行两个范围的查询,性能肯定大大提高

推荐阅读更多精彩内容