标签：
查询速度慢的原因很多，常见如下几种：
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、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。
40、避免表扫描。
41、尽可能不使用游标。
42、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在。用索引优化器优化索引。
43、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。
44、将计算的结果预先计算好放在表中，查询的时候再SELECT。
45、如果要插入大的二进制值到IMAGE列，使用存储过程，千万不要用应用程序内嵌INSERT来插入。因为应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器收到字符后又将他转换成二进制值。存储过程就没有这些动作。
46、尽量少用视图，它的效率低。对视图操作比直接对表操作慢。
47、尽量将数据的处理工作放在数据库上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。
48、函数的返回值不要太大，这样的开销很大。用户自定义函数像游标一样执行的消耗大量的资源，如果返回大的结果采用存储过程。
49、尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
50、要尽量避免在游标循环中再进行表连接的操作。
51、如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先TRUNCATE TABLE，然后DROP TABLE，这样可以避免系统表的较长时间锁定。
52、 在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
经验显示，SQL Server 性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。其实 SQL 优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的 I/O 次数，尽量避免表搜索的发生。
标签：
原文地址：http://www.cnblogs.com/ayic/p/4534823.html
