高效的数据处理机制

高效的数据处理机制

ID:42708522

大小:27.00 KB

页数:3页

时间:2019-09-20

高效的数据处理机制_第1页
高效的数据处理机制_第2页
高效的数据处理机制_第3页
资源描述:

《高效的数据处理机制》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、在应用系统中,尤其在联机事务处理系统中,对数据查询及处理速度已成为衡量应用系统成败的标准。而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法。在良好的数据库设计基础上,能有效地使用索引是SQLServer取得高性能的基础,SQLServer采用基于代价的优化模型,它对每一个提交的有关表的查询,决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O,使用索引提高性能的一个主要目标是避免全表扫描,因为全表扫描需要从磁盘上读表的每一个数据页,如果有索引指向数据值,则查询只需读几次磁盘就可以了。所以如果建立了合理的索引,优化器就能利用索引加速数据的查询过程。但是,索引并不

2、总是提高系统的性能,在增、删、改操作中索引的存在会增加一定的工作量,因此,在适当的地方增加适当的索引并从不合理的地方删除次优的索引,将有助于优化那些性能较差的SQLServer应用。实践表明,合理的索引设计是建立在对各种查询的分析和预测上的,只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQLServer索引的性能问题进行了一些分析和实践。一、聚簇索引(clusteredindexes)的使用聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由丁聚簇索引的索引页面指针指向数据页面,所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引

3、,并且建聚簇索引需要至少相当该表120%的附加空间,以存放该表的副木和索引中间页。建立聚簇索引的思想是:1、大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争,在一个高事务的环境中,对最后一页的封锁严重影响系统的吞吐量。2、在聚簇索引下,数据在物理上按顺序排在数据页上,重复值也排在一起,因而在那些包含范围检查(bctwccrix%261t;>%261t;=>%26gt;>%26gt;=)或使用groupby或orderby的查询时,一旦找到具有范围中第一个键值的行,具有后续索引值的行保证物理上毗连在一起而不必进一步搜索,避免了大范围扫描,可以大大提高查询速度。3、在一个频繁发生插入操作的

4、表上建立聚簇索引时,不要建在具有单调上升值的列(如IDENTITY)±,否则会经常引起封锁冲突。4、在聚簇索引中不要包含经常修改的列,因为码值修改后,数据行必须移动到新的位置。5、选择聚簇索引应基于where子句和连接操作的类型。聚簇索引的侯选列是:1、主键列,该列在where子句中使用并且插入是随机的。2、按范围存取的列,^0priorder%26gt;100andpriorder%261t;200。3、在groupby或orderby中使用的列。4、不经常修改的列。5、在连接操作中使用的列。二、非聚簇索引(nonclusteredindexes)的使用SQLServer缺省情况下建立的索

5、引是非聚簇索引,由于非聚簇索引不重新组织表中的数据,而是对每一行存储索引列值并用一个指针指向数据所在的页面。换句话说非聚簇索引具有在索引结构和数据本身Z间的一个额外级。一个表如果没有聚簇索引时,可有250个非聚簇索引。每个非聚簇索引提供访问数据的不同排序顺序。在建立非聚簇索引时,要权衡索引对查询速度的加快与降低修改速度之间的利弊。另外,还要考虑这些问题:1、索引需要使用多少空间。2、合适的列是否稳定。3、索引键是如何选择的,扫描效果是否更佳。4、是否有许多重复值。对更新频繁的表来说,表上的非聚簇索引比聚簇索引和根木没有索引需要更多的额外开销。对移到新页的每一行而言,指向该数据的每个非聚簇索引

6、的页级行也必须更新,有时可能还需要索引页的分理。从一个页面删除数据的进程也会有类似的开销,列外,删除进程述必须把数据移到页面上部,以保证数据的连续性。所以,建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情况:1、某列常用于集合函数(如Sum,....)o2、某列常用于join,orde3、查寻出的数据不超过表中数据量的20%o三、覆盖索引(coveringindexes)Kj使用覆盖索引是指那些索引项中包含查寻所需要的全部信息的非聚簇索引,这种索引之所以比饺快也正是因为索引页中包含了查寻所必须的数据,不需去访问数据页。如果非聚簇索引中包含结果数据,那么它的查询速度将快于聚簇索引。但是由于覆

7、盖索引的索引项比较多,要占用比较大的空间。而且update操作会引起索引值改变。所以如果潜在的覆盖查询并不常用或不太关键,则覆盖索引的增加反而会降低性能。四、索引的选择技术P_detail是住房公积金管理系统屮记录个人明细的表,有890000行,观察在不同索引下的查询运行效果,测试在C/S环境下进行,客户机是IBMPII350(内存64M),服务器是DECAlpha1000A(内存1

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。