如何优化SQL Server数据库查询

  • 来源: www.cnblogs.com 作者: sevenleaf   2010-04-16/09:22
  •       查询速度慢的原因很多,常见如下几种:
          1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷);
          2、I/O吞吐量小,形成了瓶颈效应;
          3、没有创建计算列导致查询不优化;
          4、内存不足;
          5、网络速度慢;
          6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量);
          7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷);
          8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源;
          9、返回了不必要的行和列;

          10、查询语句不好,没有优化。  
          可以通过如下方法来优化查询:
          一、硬件方面:
          1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。数据量(尺寸)越大,提高I/O越重要;
          2、纵向、横向分割表,减少表的尺寸(sp_spaceuse);
          3、升级硬件;         
          5、提高网速;
          6、扩大服务器的内存;         
          7、增加服务器 CPU个数。

          二、SQL语句方面: 
          1、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量; 
          2、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。如果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重; 
          3、注意UNion和UNion all 的区别。UNION all好;
          4、注意使用DISTINCT,在没有必要时不要用,它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的; 
          5、查询时不要返回不需要的行、列; 
          6、没有必要时不要用DISTINCT和ORDER BY,这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理;
          7、在IN后面值的列表中,将出现最频繁的值放在最前面,出现得最少的放在最后面,减少判断的次数; 
          8、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次,所以有时会慢些; 
          9、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行; 
          10、尽量少用视图,它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质:它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时,不要使用指向多个表的视图,直接从表检索或者仅仅包含这个表的视图上读,否则增加了不必要的开销,查询受到干扰.为了加快视图的查询,MsSQL增加了视图索引的功能; 
          11、如果要插入大的二进制值到Image列,使用存储过程,千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍),服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法:Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数,这样处理速度明显改善;

          12、如果使用了IN或者OR等时发现查询没有走索引,使用显示申明指定索引: Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男','女');
          13、在必要是对全局或者局部临时表创建索引,有时能够提高速度,但不是一定会这样,因为索引也耗费大量的资源。他的创建同是实际表一样;
          14、不要建没有作用的事物例如产生报表时,浪费资源。只有在必要使用事物时使用它;

          15、用OR的字句可以分解成多个查询,并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引,用UNION all执行的效率更高.多个OR的字句没有用到索引,改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引;
          16、当用Select INTO时,它会锁住系统表(sysobjects,sysindexes等等),阻塞其他的连接的存取。创建临时表时用显示申明语句,而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到 Select INTO 会锁住系统表,Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表,或者临时表变量;
          17、一般在GROUP BY 个HAVING字句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优:select 的Where字句选择所有合适的行,Group By用来分组个统计行,Having字句用来剔除多余的分组。这样Group By 个Having的开销小,查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算,只是分组,那么用Distinct更快; 
          18、一次更新多条记录比分多次更新每次一条快,就是说批处理好39、少用临时表,尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好;
          19、在SQL2000下,计算字段是可以索引的,需要满足的条件如下:
          a、计算字段的表达是确定的
          b、不能用在TEXT,Ntext,Image数据类型
          c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, ……;
          20、尽量将数据的处理工作放在服务器上,减少网络的开销,如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句,是控制流语言的集合,速度当然快。反复执行的动态SQL,可以使用临时存储过程,该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持,所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算,函数的返回值不要太大,这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源,如果返回大的结果采用存储过程;
          21、不要在一句话里再三的使用相同的函数,浪费资源,将结果放在变量里再调用更快;
          22、Select COUNT(*)的效率教低,尽量变通他的写法,而EXISTS快.同时请注意区别: select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!


    评论 {{userinfo.comments}}

    {{money}}

    {{question.question}}

    A {{question.A}}
    B {{question.B}}
    C {{question.C}}
    D {{question.D}}
    提交

    驱动号 更多