SQL 优化总结(一)
查询速度慢的原因
查询速度慢原因很多,常见如下几种:
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、索引应该尽量小,使用字节数小的列建索引好(参照索引的创建) ,不要对有限的几个值的字段建单一索引如性别字段 ,索引越小越好。
3、索引不能建得太多和太大。
4、在取值范围比较小的情况下,数字型字段上基本没有建立索引的必要。建立索引还可能会增加表的负担,查询速度甚至会减慢。
5、在排序过程中,索引的使用非常关键。建议使用聚集索引。