SQL Server数据库性能优化技巧

查询速度慢的原因很多，常见如下几种：

1、没有索引或者没有用到索引；

2、I/O吞吐量小，形成了瓶颈效应；

3、内存不足；

4、网络速度慢；

5、查询出的数据量过大；

6、锁或者死锁；

7、返回了不必要的行和列；

8、查询语句不好，没有优化。

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

硬件/网络方面

1、升级硬件。

2、提高网速。

3、扩大服务器的内存。

4、增加服务器CPU个数。

5、把数据、日志、索引放到不同的I/O设备上。

6、DB Server和APP Server分离。

7、应用分布式分区视图。

索引方面

8、根据查询条件建立索引，优化索引。

9、索引应该尽量小，使用字节数小的列建索引好。

10、不要对有限的几个值的字段建单一索引（如性别字段）。

11、对于查询字段的值很长的建全文索引。

12、要注意索引的维护，周期性重建索引，重新编译存储过程。

13、如果使用了IN或者OR等时发现查询没有走索引，使用显示声明指定索引。

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

15、在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。

16、如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。

17、如果某列存在空值，即使对该列建索引也不会提高性能。

SQL语句方面

18、如果是使用LIKE进行查询的话，简单的使用索引是不行的，LIKE 'a%' 使用索引，LIKE '%a' 不使用索引，用 LIKE '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。

19、查询时不要返回不需要的行、列。

20、一定要将函数和列名分开。如果必须用函数的时候，创建计算列再创建索引来替代。

21、NOT IN会多次扫描表，使用EXISTS、NOT EXISTS，IN，LEFT OUTER JOIN来替代，特别是左连接，而EXISTS比IN更快，最慢的是NOT操作。

22、BETWEEN在某些时候比IN速度更快,BETWEEN能够更快地根据索引找到范围。

23、用OR的子句可以分解成多个查询，并且通过UNION连接多个查询。它们的速度只同是否使用索引有关。多个OR的子句没有用到索引，改写成UNION的形式再试图与索引匹配。

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

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

26、尽量使用批处理。

27、不要在一句话里再三的使用相同的函数，浪费资源，将结果放在变量里再调用更快。

28、分析select emp_name form employee where salary > 3000 在此语句中若salary是FLOAT类型的，则优化器对其进行优化为CONVERT(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。对其它类型也是一样。

29、注意WHERE子句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。

30、尽量使用EXISTS代替SELECT COUNT(1)来判断是否存在记录，COUNT函数只有在统计表中所有行数时使用，而COUNT (1)比COUNT (*)更有效率。

31、尽量使用“>=”，不要使用“>”。

32、注意表之间连接的数据类型，避免不同类型数据之间的连接。

33、尽量避免使用DISTINCT、ORDER BY、GROUP BY、HAVING、JOIN、CUMPUTE。

34、在海量查询时尽量少用格式转换。

35、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

其它方面

36、纵向、横向分割表，减少表的尺寸。

37、设置自动收缩日志。

38、周期性清理日志。

39、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。