查询速度慢的原因
查询速度慢原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock，sp_who，活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060) 字节，8个页面为一个盘区，按照B树存放。
SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。
其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
一、 索引
1、 索引的建立
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
(1) 有大量重复值、且经常有范围查询(between, >;,< ，>;=,< =) 和order by、group by发生的列，可考虑建立群集索引；
|
索引 |
语句 |
时间 |
|
date上有个非群集索引 |
select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 |
(25秒) |
|
date上的一个群集索引 |
select count(*) from record where date > |
(14秒) |
在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。
(2) 经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
(3) 组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。
|
索引 |
语句 |
时间 |
|
place，date，amount组合索引 |
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 |
(26秒) |
|
date，place，amount组合索引 |
select count(*) from record where date>'19991201' and date < '19991214' and amount >2000 |
(< 1秒) |
它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。
(4) 在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
(5) 在频繁进行排序或分组(即进行group by或order by操作) 的列上建立索引。
(6) 在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
(7) 如果待排序的列有多个，可以在这些列上建立复合索引(compound index) 。
(8) 根据查询条件,建立索引,优化索引、优化访问方式。
2、索引应该尽量小，使用字节数小的列建索引好(参照索引的创建) ,不要对有限的几个值的字段建单一索引如性别字段 ，索引越小越好。
３、索引不能建得太多和太大。
4、在取值范围比较小的情况下，数字型字段上基本没有建立索引的必要。建立索引还可能会增加表的负担，查询速度甚至会减慢。
5、在排序过程中，索引的使用非常关键。建议使用聚集索引。