避免全表扫描的情况

 1.避免在 where 子句中使用!=或<>操作符

 2.避免全表扫描,在 where 及 order by 涉及的列上建立索引。

 3.应尽量避免在 where 子句中对字段进行 null 值判断,可以在num上设置默认值0,确保表中num列没有null值,:
   
 4.应尽量避免在 where 子句中使用 or 来连接条件,unoin al 代替or :

 5.避免前置%

 6.in 和 not in 也要慎用,否则会导致全表扫描,改用between and

 7.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

其他：

 12.不要写一些没有意义的查询,如需要生成一个空表结构:

 13.很多时候用 exists 代替 in 是一个好的选择

 15.索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,一个表的
索引数最好不要超过6个.

 16.应尽可能的避免更新 clustered 索引,因为 clustered 索引的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整
,会耗费相当大的资源。需要频繁更新 clustered 索引,那么需要考虑是否将 clustered建索引。

 17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询
和连接时会 逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。

 18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字
段内搜索效率显然要高些。

 23.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大
,为了缓和系统表的资源,应先create table,然后insert。

 24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间
锁定。

 28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。
    无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

 29.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

 30.尽量避免大事务操作,提高系统并发能力。

查询速度慢的原因:

没有索引或者没有用到索引、I/O吞吐量小、内存不足 、网络速度慢 、查询出的数据量过大、锁或者死锁、读写竞争资源、返回了不必要的行和列 、查询语句不好,没有优化 

可以通过如下方法来优化查询 

1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。数据量(尺寸)越大,提高I/O越重
要. 

2、纵向、横向分割表,减少表的尺寸(sp_spaceuse) 

3、升级硬件 

4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,使用字节
数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段 

5、提高网速; 

6、配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。运行   Microsoft   SQL   Server?   2000   时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的   1.5   倍。如果另外安装了全文检索功能,并打算运行   Microsoft   搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将   SQL   Server   max   server   memory   服务器配置选项配置为物理内存的   1.5   倍(虚拟内存大小设置的一半)。 

7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任
务,就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP   BY字句同时执行,SQL   SERVER根据系统的负载情况决定最优的并行等级,
复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT, DELETE还不能并行处理。 

8、如果是使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。   like   ‘a%’   使用索引   like   ‘%a’   不使用索引用  
 like   ‘%a%’   查询时,查询耗时和字段值总长度成正比,所以不能用CHAR类型,而是VARCHAR。对于字段的值很长的建全文索引。 

9、DB   Server   和APPLication   Server   分离;OLTP和OLAP分离 

10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器,但它们相互协作分担系统的处理负荷。这种通过分区数据形
成数据库服务器联合体的机制能够扩大一组服务器,以支持大型的多层   Web   站点的处理需要。有关更多信息,参见设计联合数据库服务器。(参照
SQL帮助文件’分区视图’) 
    a、在实现分区视图之前,必须先水平分区表  
    b、在创建成员表后,在每个成员服务器上定义一个分布式分区视图,并且每个视图具有相同的名称。这样,引用分布式分区视图名的查询可以在任
何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样,但其实每个服务器上只有一个成员表和一个分布式分区视图
。数据的位置对应用程序是透明的。 

11、重建索引   DBCC   REINDEX   ,DBCC   INDEXDEFRAG,收缩数据和日志   DBCC   SHRINKDB,DBCC   SHRINKFILE.   设置自动收缩日志.对于大
的数据库不要设置数据库自动增长,它会降低服务器的性能。 

12、Commit和rollback的区别   Rollback:回滚所有的事物。   Commit:提交当前的事物.   没有必要在动态SQL里写事物,如果要写请写在外面如:  
 begin   tran   exec(@s)   commit   trans   或者将动态SQL   写成函数或者存储过程。 

13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。如
果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重。 

14、SQL的注释申明对执行没有任何影响  

16、用Profiler来跟踪查询,得到查询所需的时间,找出SQL的问题所在;用索引优化器优化索引 

17、注意UNion和UNion all 的区别。UNION   all好 

20、用sp_configure   ‘query   governor   cost   limit’或者SET   QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资
源超出限制时,服务器自动取消查询,在查询之前就扼杀掉。 SET   LOCKTIME设置锁的时间 

21、用select  top  100 /  10  Percent   来限制用户返回的行数或者SET   ROWCOUNT来限制操作的行  

23、使用Query  Analyzer,查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源,我们优化的重点是这些慢的地
方。 

24、如果使用了IN或者OR等时发现查询没有走索引,使用显示申明指定索引:   SELECT   *   FROM   PersonMember   (INDEX   =   IX_Title)  
WHERE   processid   IN   (‘男’,‘女’) 

26、MIN()   和   MAX()能使用到合适的索引 

27、数据库有一个原则是代码离数据越近越好,所以优先选择Default,依次为Rules,Triggers,  Constraint(约束如外健主健CheckUNIQUE……,数据
类型的最大长度等等都是约束),Procedure.这样不仅维护工作小,编写程序质量高,并且执行的速度快。 

29、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。     

32、用OR的字句可以分解成多个查询,并且通过UNION   连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引,用UNION  
all执行的效率更高.多个OR的字句没有用到索引,改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。  

34、没有必要时不要用DISTINCT和ORDER  BY,这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION   和UNION   ALL一样的道理。   

35、在IN后面值的列表中,将出现最频繁的值放在最前面,出现得最少的放在最后面,减少判断的次数 

37、一般在GROUP   BY   个HAVING字句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优:select   的
Where字句选择所有合适的行,Group   By用来分组个统计行,Having字句用来剔除多余的分组。这样Group   By   个Having的开销小,查询快.对于大
的数据行进行分组和Having十分消耗资源。如果Group   BY的目的不包括计算,只是分组,那么用Distinct更快 

38、一次更新多条记录比分多次更新每次一条快,就是说批处理好 

44、当服务器的内存够多时,配制线程数量   =   最大连接数+5,这样能发挥最大的效率;否则使用   配制线程数量 <最大连接数启用SQL   SERVER
的线程池来解决,如果还是数量   =   最大连接数+5,严重的损害服务器的性能。 

47、语句中若salary是Float类型的,则优化器对其进行优化为Convert(float,3000),因为3000是个整数,我们应在编程时使用3000.0而不要等运行时
让DBMS进行转化。