【摘要】本文从DBMS的查询优化器对SQL查询语句进行性能优化的角度出发,结合数据库理论,从查询表达式及其多种查询条件组合对数据库查询性能优化进行分析,总结出多种提高数据库查询性能优化策略,介绍索引的合理建立和使用以及高质量SQL查询语句的书写原则,从而实现高效的查询,提高系统的可用性。 
【关键词】SQL查询语句,索引,性能优化 

1.引言

在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,索引的运用与复杂视图的编写等体会不出SQL语句各种写法的性能优劣,但是应用系统实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性。 面对海量数据查询,分时段对大批量数据进行删除、更新和插入操作,抓住需要优化的主要方面,针对不同的情况从如何采用高效的SQL入手来进行。

2.索引的正确使用 在海量数据表中,基本每个表都有一个或多个的索引来保证高效的查询,索引的使用需要遵循以下使用原则:

(1) 当插入的数据为数据表中的记录数量10%以上时, 首先需要删除该表的索引来提高数据的插入效率,当数据全部插入后再建立索引。 
(2) 避免在索引列上使用函数或计算,在WHERE子句中,如果索引列是函数的一部分,优化器将不使用索引而使用全表扫描。举例:     
    wk_ad_begin({pid : 21});wk_ad_after(21, function(){$('.ad-hidden').hide();}, function(){$('.ad-hidden').show();});
低效: select  *  from  table  where  salary * 12  >  25000;  

高效: select  *  from  table  where  salary  >  25000/12; 

低效: select * from table1 where name='zhangsan'  and  tID > 10000 

高效: select * from table1 where tID > 10000 and name='zhangsan'
如果tID是一个聚合索引,那么后一句仅仅从表的10000条以后的记录中查找就行了;而前一句则要先从全表中查找看有几个name='zhangsan'的,而后再根据限制条件条件tID>10000来提出查询结果。 
(3) 避免在索引列上使用NOT和”!=”或<> , 索引只能告诉什么存在于表中, 而不能告诉什么不存在于表中,当数据库遇到NOT和”!=”时,就会停止使用索引转而执行全表扫描。 
(4) 索引列上用>=替代>
高效:   select  *  from  table  where  Deptno >=4  
低效: select * from table where Deptno >3
两者的区别在于, 前者table将直接跳到第一个Deptno等于4的记录而后者将首先定位到Deptno=3的记录并且向前扫描到第一个Deptno大于3的记录。 
(5) 函数的列启用索引方法,如果一定要对使用函数的列启用索引,Oracle9i以上版本新的功能:基于函数的索引(Function-Based Index)是一个较好的方案,但该类型索引的缺点是只能针对某个函数来建立和使用该函数。 
create  index  EMP_I  ON  EMP (upper( ename)); /*建立基于函数的索引*/  

select  *  from EMP  where  upper( ename) = „BLACKSNAIL‟; /*将使用索引*/ 

3.  SQL语句性能优化

 3.1 WHERE子句中的连接顺序 
ORACLE采用自下而上的顺序解析where子句,根据这个原理,表之间的连接必须写在其它where条件之前,那些可以过滤掉最大数量记录的条件必须写在where子句的末尾。 
低效:Select  *  from  table where Salary > 50000  and Job = ‘MANAGER’ and 25 < (Select count(*) from table  where Mgr=table.Empno);  

高效:Select  *  from  table where 25 < (select count(*) from table   where Mgr=table.Empno)  and Salary> 50000 and Job = ‘MANAGER’;
3.2 用EXISTS替代IN 
在许多基于基础表的查询中,为了满足一个条件往往需要对另一个表进行联接,例如在ETL过程写数据到模型时经常需要关联10个左右的维表,从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别:ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程, 在这种情况下,使用EXISTS而不用IN将提高查询的效率。
3.3 用NOT EXISTS替代NOT IN 
子查询中,NOT IN子句将执行一个内部的排序和合并,无论在哪种情况下,NOT IN都是最低效的,因为它对子查询中的表执行了一个全表遍历。用NOT EXISTS替代NOT IN将提高查询的效率。
3.4  !=或<> 操作符(不等于)
不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。推荐方案:用其它相同功能的操作运算代替,如a<>0 改为 a>0 or a<0 。 
3.5  IS NULL 或IS NOT NULL操作(判断字段是否为空) 
判断字段是否为空一般是不会应用索引的,因为B树索引是不索引空值的。推荐方案:用其它相同功能的操作运算代替,如a is not null 改为 a>0 或a>’’等。不允许字段为空,而用一个缺省值代替空值。 
3.6  > 及 < 操作符(大于或小于操作符) 
大于或小于操作符一般情况下是不用调整的,因为它有索引就会采用索引查找,但有的情况下可以对它进行优化,如一个表有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的记录索引。
3.7 优化GROUP BY 
提高GROUP BY 语句的效率,可以通过将不需要的记录在GROUP BY 之前过滤掉。  
低效: Select  Job, Avg(Salary)  from  table  group  by  Job  having  Job = ‘PRESIDENT’ OR  Job  = ‘MANAGER’
高效: Select Job, Avg(Salary) from table Where Job = ‘PRESIDENT’ OR Job = ‘MANAGER’ group by Job
3.8  LIKE操作符 
LIKE操作符可以应用通配符查询,里面的通配符组合可能达到几乎是任意的查询,但是如果用得不好则会产生性能上的问题,如LIKE ‘%5400%’ 这种查询不会引用索引,而LIKE ‘X5400%’则会引用范围索引。一个实际例子:用Students表中学生编号后面的标识号可来查询学生 Sno LIKE ‘%5400%’ 这个条件会产生全表扫描,如果改成Sno LIKE ’X5400%’ OR  Sno LIKE ’B5400%’ 则会利用Sno的索引进行两个范围的查询,性能肯定大大提高。 
3.9 有条件的使用UNION-ALL 替换UNION 
针对多表连接操作的情况很多,有条件的使用UNION-ALL 替换UNION的前提是:所连接的各个表中无主关键字相同的记录,因为UNION ALL 将重复输出两个结果集合中相同记录。UNION在进行表链接后会筛选掉重复的记录,所以在表链接后会对所产生的结果集进行排序运算,删除重复的记录再返回结果。当SQL语句需要UNION两个查询结果集合时,这两个结果集合会以UNION-ALL的方式被合并,然后在输出最终结果前进行排序。如果用UNION ALL替代UNION, 这样排序就不是必要了,效率就会因此得到提高3-5倍。
3.10 避免where 子句中对字段进行表达式操作或对字段进行函数操作 
因为若where 子句中如果索引列是表达式或函数的一部分,优化器就不能使用分布统计信息,这将导致引擎放弃使用索引而进行全表扫描。 
低效:Select  name from table  where  substring (id, 1, 1) = 'C' 

低效:Select  name from table  where  salary * 10 > 

4.其它的优化方法

数据库的查询优化方法不仅仅是索引和SQL语句的优化,其他方法的合理使用同样也能很好的对数据库查询功能起到优化作用。我们就来列举几种简单实用的方法。
4.1 使用临时表加速查询 
   创建临时表在一些情况下可以避免多重排序操作。但所创建的临时表的行要比主表的行少,其物理顺序就是所要求的顺序,这样就减少了输入和输出,降低了查询的工作量,提高了查询效率,而且临时表的创建并不会反映主表的修改。  
   比如:如果直接在存储上万条数据的永久表上重复循环进行统计、查询,其执行效率非常低,但是,先从存储大量数据的永久表中提取符和条件的存放到临时表后,在临时表上执行操作,效率会大大提高。
4.2 避免对大型表 行数据的顺序存取 
在嵌套查询中,对表的顺序存取对查询效率可能产生致命的影响。 
比如采用顺序存取策略,一个嵌套3层的查询,如果每层都查询1000行,那么这个查询就要查询10亿行数据。
避免这种情况的主要方法就是对连接的列进行索引。 两个表:学生表(学号、姓名、年龄……)       选课表(学号、课程号、成绩) 
如果两个表要做连接,就要在“学号”这个连接字段上建立索引。 
4.3  避免或简化排序  
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时,优化器就避免了排序的步骤。以下是一些影响因素:
4.1.索引中不包括一个或几个待排序的列
4.2. group by或order by子句中列的次序与索引的次序不一样 
4.3. 排序的列来自不同的表 为了避免不必要的排序,就要正确地增建索引,合理地合并数据库表(尽管有时可能影响表的规范化,但相对于效率的提高是值得的)。如果排序不可避免,那么应当试图简化它,如缩小排序的列的范围等。
4.4 避免相关子查询如果在主查询和where子句中的查询中同时出现了一个列的标签,这样就会使主查询的列值改变后,子查询也必须重新进行一次查询。因为查询的嵌套层次越多,查询的效率就会降低,所以我们应当避免子查询。如果无法避免,就要在查询的过程中过滤掉尽可能多的。 

4.5 用排序来取代非顺序存取 非顺序磁盘存取是最慢的操作,表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况,使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。 有些时候,用数据库的排序能力来替代非顺序的存取能改进查询。 

5. 总结 
对于海量数据的查询优化,我们要抓住关键问题,写出高质量的SQL语句,提高系统的可用性。在计算实际的查询处理代价时,必须考虑优化本身的时间和空间开销。如果选择最佳的处理方案的开销太大,则可能得不偿失。实际上,查询优化在合理的优化处理开销下,寻找较好的处理方案,而不一定是最佳方案
												





											

SQl语句查询性能优化的更多相关文章

  1. SQL SERVER 查询性能优化——分析事务与锁(五)

    SQL SERVER 查询性能优化——分析事务与锁(一) SQL SERVER 查询性能优化——分析事务与锁(二) SQL SERVER 查询性能优化——分析事务与锁(三) 上接SQL SERVER ...

  2. SQL Server 查询性能优化 相关文章

    来自: SQL Server 查询性能优化——堆表.碎片与索引(一) SQL Server 查询性能优化——堆表.碎片与索引(二) SQL Server 查询性能优化——覆盖索引(一) SQL Ser ...

  3. Sql Server查询性能优化之走出索引的误区

    据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是, ...

  4. SQL Server查询性能优化——堆表、碎片与索引(二)

    本文是对 SQL Server查询性能优化——堆表.碎片与索引(一)的一些总结.  第一:先对 SQL Server查询性能优化——堆表.碎片与索引(一)中的例一的SET STATISTICS IO之 ...

  5. SQL Server查询性能优化——覆盖索引(二)

    在SQL Server 查询性能优化——覆盖索引(一)中讲了覆盖索引的一些理论. 本文将具体讲一下使用不同索引对查询性能的影响. 下面通过实例,来查看不同的索引结构,如聚集索引.非聚集索引.组合索引等 ...

  6. SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用

    近段时间以来,一直在探究SQL Server查询性能的问题,当然也漫无目的的查找了很多资料,也从网上的大神们的文章中学到了很多,在这里,向各位大神致敬.正是受大神们无私奉献精神的影响,所以小弟也作为回 ...

  7. SQL Server 查询性能优化——覆盖索引

    覆盖索引又可以称为索引覆盖. 解释一: 就是select的数据列只用从索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖. 解释二: 索引是高效找到行的一个方法,当能通过检索索引 ...

  8. SQL Server查询性能优化——覆盖索引(一)

    覆盖索引又可以称为索引覆盖. 解释一: 就是select的数据列只用从索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖. 解释二: 索引是高效找到行的一个方法,当能通过检索索引 ...

  9. SQL Server查询性能优化——创建索引原则(一)

    索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页 就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索 ...

随机推荐

  1. 用JS做一个简单的电商产品放大镜功能

    使用js制作一个简单的产品放大图 购物网站的产品页经常会放有一个产品展示图区.该图区有一个功能就是产品图的放大功能,移动左侧的焦点区域,可以放大细节部分观看,详情如下图.实现该功能的方法也非常简单. ...

  2. (四)SQL Server分区管理

    一.拆分分区(SPLIT) 在已有分区上添加一个新分区. 如下图所示,将分区03拆分成03和04分区,拆分方式先锁定旧03分区的所有数据,后将旧03分区相关数据迁移到分区04,最后删除旧03上的对应分 ...

  3. Android Volley完全解析

    1. Volley简介 我们平时在开发Android应用的时候不可避免地都需要用到网络技术,而多数情况下应用程序都会使用HTTP协议来发送和接收网络数据.Android系统中主要提供了两种方式来进行H ...

  4. C++ Primer学习笔记一

    /* 题目要求把字符串BRGBBGRRGBBGBBBGRRGBGRG按RGB顺序排列,空间复杂度为O(1) */#include<iostream> using namespace std ...

  5. 无法启动:此实现不是Windows平台FIPS验证的加密算法的一部分

    个别同学可能会在启动订票助手.NET的时候发现这个提示: 出现这个问题的原因是订票助手.NET使用了MD5算法,而系统的组策略安全设置导致无法使用此算法.要修正此问题,请按照如下操作(两种方法任选其一 ...

  6. [jAudio] JAVA上经典特征提取工具

    1.下载Jar包后引入 现在的问题是jAudio通常是给人UI进行操作的,直接使用怎么办? 看了源码,发现特征提取是通过类之间交叉调用实现的,是否有办法整合一下?

  7. oStrictHostKeyChecking=no 参数

    应用在脚本当中,避免使用域名链接服务器的时候,检查knows_hosts文件

  8. springboot+springmvc+mybatis项目整合

    介绍: 上篇给大家介绍了ssm多模块项目的搭建,在搭建过程中spring整合springmvc和mybatis时会有很多的东西需要我们进行配置,这样不仅浪费了时间,也比较容易出错,由于这样问题的产生, ...

  9. 63. Unique Paths II(中等, 能独立做出来的DP类第二个题^^)

    Follow up for "Unique Paths": Now consider if some obstacles are added to the grids. How m ...

  10. Jmeter实现dubbo接口压测案例

    当前项目中重构了消息服务,需要对消息服务接口做性能压测,评估消息服务的性能情况 通过和开发对接,目前消息服务是通过dubbo接口对内提供服务,所以才有了这边文章的记录 最初的压测这个dubbo接口有三 ...