重建索引提高查询效率

sqlserver重建(rebuild)索引可以提高查询速度

当随着表的数据量不断增长,很多存储的数据进行了不适当的跨页(sqlserver中存储的最小单位是页,页是不不可再分的),会产生很多索引的碎片。这时候需要重建索引来提高查询性能

 

SQL Server 2005在硬盘中用8KB页面在数据库文件内存放数据。缺省情况下这些页面及其包含的数据是无组织的。为了使混乱变为有序,就要生成索引。生成索引后,就有了索引页和数据页之分:数据页用来保存用户写入的数据信息;索引页存放用于检索列的数据值清单(关键字)和索引表中该值所在纪录的地址指针。索引分为簇索引和非簇索引,簇索引实质上是将表中的数据排序,就好像是字典的索引目录。非簇索引不对数据排序,它只保存了数据的地址。向一个带簇索引的表中插入数据,当数据页达到100%时,由于页面没有空间插入新的的纪录,这时就会发生分页,SQL Server 将大约一半的数据从满页中移到空页中,从而生成两个1/2满页。这样就有大量的空的数据空间。簇索引是双向链表,在每一页的头部保存了前一页、后一页以及分页后数据移出的地址。由于新页可能在数据库文件中的任何地方,因此页面的链接不一定指向磁盘的下一个物理页。链接可能指向了另一个区域,这就形成了分块,从而减慢了系统的速度。对于带簇索引和非簇索引的表来说,非簇索引的关键字是指向簇索引的,而不是指向数据页的本身。

为了克服数据分块带来的负面影响,需要重构表的索引,这是非常费时的,因此只能在需要时进行。可以通过DBCC SHOWCONTIG来确定是否需要重构表的索引。

DBCC SHOWCONTIG(TABLE_NAME)

返回结果:

DBCC SHOWCONTIG 正在扫描 ‘TABLE_NAME‘ 表...
表: ‘TABLE_NAME‘ (128211707);索引 ID: 1,数据库 ID: 5
已执行 TABLE 级别的扫描。
- 扫描页数................................: 564273
- 扫描区数..............................: 70543
- 区切换次数..............................: 70543
- 每个区的平均页数........................: 8.0
- 扫描密度 [最佳计数:实际计数].......: 99.99% [70535:70544]
- 逻辑扫描碎片 ..................: 0.01%
- 区扫描碎片 ..................: 2.52%
- 每页的平均可用字节数........................: 684.6
- 平均页密度(满).....................: 91.54%
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

最佳计数为70535,实际计数为70544,这表明该表有分块,需要重构表索引,扫描密度为100%则表示没有分块

如何查看索引的使用情况:
SELECT index_type_desc,alloc_unit_type_desc,avg_fragmentation_in_percent,fragment_count,avg_fragment_size_in_pages,page_count,record_count,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(‘db_name‘),OBJECT_ID(‘table_name),NULL,NULL,‘Sampled‘)

上面的语句是查询数据库db_name的表table_name的索引使用情况。

查询结果中的列avg_fragment_size_in_pages值超过40%就需要重建索引

重建索引

ALTER INDEX 索引名 ON  表名 REBUILD

时间: 2024-10-17 17:34:16

重建索引提高查询效率的相关文章

数据库建索引提高查询效率

1.索引作用 在索引列上,除了上面提到的有序查找之外,数据库利用各种各样的快速定位技术,能够大大提高查询效率.特别是当数据量非常大,查询涉及多个表时,使用索引往往能使查询速度加快成千上万倍. 例如,有3个未索引的表t1.t2.t3,分别只包含列c1.c2.c3,每个表分别含有1000行数据组成,指为1-1000的数值,查找对应值相等行的查询如下所示. SELECT c1,c2,c3 FROM t1,t2,t3 WHERE c1=c2 AND c1=c3 此查询结果应该为1000行,每行包含3个相

MongoDB学习笔记~索引提高查询效率

索引这个东西大家不会陌生,只要接触到稍微大一点的数据,都会用到这东西,它可以提升查询的速度,相当代价就是占用了更多的存储空间,这也是正常的,符合“能量守恒定理”,哈哈!今天说的是MongoDB里的索引,在我进行对500万数据进行查询测试时,发现如果你的查询字段不加索引,那是相当恐怖的,一个简单的查询(单字段)要耗时30多秒,这种操作,基本可以认为服务器挂了,哈哈!当为字段加了索引之后,查询速度为ms级,100毫秒以内的速度真是把经兴奋坏了,呵呵! 建立索引 db.tableName.ensure

在一个千万级的数据库查寻中,如何提高查询效率?

在一个千万级的数据库查寻中,如何提高查询效率? 1)数据库设计方面:  a.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. b.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0

mysql 创建索引、重建索引、查询索引、删除索引 转自:http://www.phpernote.com/mysql/942.html

本篇文章主要是对MySQL索引操作方法做了一下总结,包括创建索引.重建索引.查询索引.删除索引的操作.以下所列示例中中 `table_name` 表示数据表名,`index_name` 表示索引名,column list 表示字段列表(如:`id`,`order_id`). 1.创建索引 索引的创建可以在CREATE TABLE语句中进行,也可以单独用CREATE INDEX或ALTER TABLE来给表增加索引.以下命令语句分别展示了如何创建主键索引(PRIMARY KEY),联合索引(UNI

利用SQL索引提高查询速度

1.合理使用索引 索引是数据库中重要的数据结构,它的根本目的就是为了提高查询效率.现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构. 索引的使用要恰到好处,其使用原则如下: 在经常进行连接,但是没有指定为外键的列上建立索引,而不经常连接的字段则由优化器自动生成索引. 在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引. 在条件表达式中经常用到的不同值较多的列上建立检索,在不同值少的列上不要建立索引.比如在雇员表的“性别”列上只有“男”与“女”两个不同值

Lucene4.6查询时完全跳过打分,提高查询效率的实现方式

由于索引的文件量比较大,而且应用中不需要对文档进行打分,只需要查询出所有满足条件的文档.所以需要跳过打分来提高查询效率.一开始想用ConstantScoreQuery,但是测试发现这个类虽然让所有返回的文档打分都为1.0并没有提高查询效率,因此查资料发现可以用Filter实现跳过打分,其中又以 FieldCacheTermsFilter为最佳,其缓存机制给查询的速度提升极为明显.后面有空的时候给出完整实现,这两天略忙. 核心代码: Query query = new TermQuery(new

如何使用索引提高查询速度

1.前言在web开发中, 页面模板,业务逻辑(包括缓存.连接池)和数据库这三个部分,数据库在其中负责执行SQL查询并返回查询结果,是影响网站速度最重要的性能瓶颈.本文主要 针对MySql数据库,双十一的电商大战,引发了淘宝技术热议,而淘宝现在去IOE(I代表IBM的缩写,即去IBM的存储设备和小型机;O是代表 Oracle的缩写,也即去Oracle数据库,采用MySQL和Hadoop替代的解决方案,;E是代表EMC2,即去EMC2的设备性,用PC Server替代EMC2),大量采用MySql集

oracle提高查询效率的34条方法

注:本文来源:远方的守望者  <oracle提高查询效率的34条方法> oracle提高查询效率的34条方法 1.选择最有效率的表名顺序 (只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是

es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?

面试题es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?面试官心理分析这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥?其实 es 性能并没有你想象中那么好的.很多时候数据量大了,特别是有几亿条数据的时候,可能你会懵逼的发现,跑个搜索怎么一下 5~10s,坑爹了.第一次搜索的时候,是 5~10s,后面反而就快了,可能就几百毫秒.你就很懵,每个用户第一次访问都会比较慢,比较卡么?所以你要是没玩儿过 es,或者就是自己玩玩儿 demo,被问到这个问题容易懵逼,显示出你对