基于SQLServer数据库查询优化的几点思考.docx

?

?

基于SQLServer数据库查询优化的几点思考

?

?

论文导读：影响SQLServer性能的因素很多。合理的使用索引能在很大程度上加速数据的读取。使用合理的索引是优化查询性能的有效手段之一。

关键词：SQLServer，数据库模型，优化查询，索引

?

正文:

随着计算机技术的飞速发展，作为企业级数据库服务器SQLServer在性能、可扩展性等方面对于数据库系统提出了更为严格的要求。依据SQLServer的响应时间、吞吐量和可扩展性等方面来判定其性能。影响SQLServer性能的因素很多，大致分为：应用程序的体系结构的设计、数据库模型和物理设计、事务与隔离级别的选择、Transact—SQL语句设计、硬件资源配置及SQLServer配置参数设定等几个方面。我们就数据库模型设计、Transact—SQL语句设计和常用优化技术三方面来讨论。

一、合理设计数据库模型

设计不良的数据库模型会导致数据查询、修改等操作效率的降低。为了避免这类问题，可以从以下几点考虑。

1.数据库模型的范式

范式是对关系规范化的约束要求，规范化理论将关系应该满足的规范要求分成几级，主要包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、鲍依斯-科得范式（BCNF）、第四范式（4NF）和第五范式（5NF）等。范式越高，越能够有效消除数据冗余，理顺数据隶属关系，保持数据库的完整性，提高数据库的稳定性和扩展性。但是越高的范式需要更多的表，在检索同样信息的查询中需要的连接操作也会更多，造成需要更多的系统机缘来优化执行，最终导致数据库系统中查询的性能的降低。以下面两个模型为例，在模型1使用一张表代表职工；模型2中将职工表的信息细化成为两张表——职工表和部门表。

模型1：

Employee(

Emp_NOchar(8)notnull,

Emp_Namechar(8),

Emp_addrschar(20),

Emp_birthdatetime,

Emp_wyerdatetime,

Depart_Namechar(10),

Depart_phonechar(20)

)

模型2：

Employee(

Emp_NOchar(8)notnull,

Emp_Namechar(8),

Emp_addrschar(20),

Emp_birthdatetime,

Emp_wyerdatetime

)

Department(

Depart_NoChar(8),

Depart_Namechar(10),

Depart_phonechar(20)

)

若查询职员和部门信息,对于模型1,只需进行简单扫描即可,而模型2则需要进行职员表和部门表的连接操作;然而模型1相对于模型2存在数据冗余,若进行部门电话信息的更新操作,模型1必须更新多行记录及更多的加锁和日志记录,而模型2则只需更新部门表中的移行记录即可。由此看出，选择合适的数据库模型，影响着应用程序的性能。科技论文，优化查询。

2.使用合理的索引

合理的使用索引能在很大程度上加速数据的读取，提高查询速度，使应用程序获得更好的性能，相反，不必要的索引会增加数据修改操作不必要的开支，浪费数据库中的空间。因此，使用合理的索引是优化查询性能的有效手段之一。

(1)聚集索引的使用

聚集索引的建立使得数据的物理存储与索引数据的顺序一致,因此对于提高查询效率十分有效。诸如Between、、=等一类需要排序数据来匹配聚集码的范围值查询是非常有效的。同样，对于访问连续列或者含有重复值很少的大量数据列，亦或者经常使用连接、排序(ORDERBY)或分组(GROUPBY)统计等查询访问的情况也很适用。SQLServer在声明PRIMARYKEY(主键)约束时，为主键同时创建了唯一聚集索引，但在某种情况下，反而会造成查询速度的减慢。以模型2中的数据表employee为例，查询工龄超过10年的职工信息，使用下列代码段查看查询花费时间：

DECLARE@tdatetime

Set@t=getdate()

Select*fromemployeewhereemp_wyerdateadd(yy,-10,getdate())

Select‘该查询执行所花费的时间(毫秒)为’=datediff(ms,@t,getdate())

通过设置分别在主键(emp_no)上建立聚集索引，在emp_wyer(参加工作时间)建立非聚集索引与在主键(emp_no)上建立非聚集索引，在emp_wyer上建立聚集索引两种情况的耗时对比，发现并不是在主键上建立聚集索引都是最好的选择。因此，有时在主键约束上设置nonclustered对于查询速度的提高会更有效。

(2)非聚集索引的使用

查询优化器对非聚集索引的