有些表进行了索引碎片的重建为什么碎片还是那么多

来源：蜘蛛抓取(WebSpider) 时间：2017-03-19 09:45 标签： 索引碎片

可以通过重新排列索引碎片行和頁面是物理和逻辑顺序相符来解决索引碎片中的碎片问题可以物理重排索引碎片的叶子页面使其遵循索引碎片的逻辑顺序：

重建聚集/非聚集索引碎片：

最大限度的减少了碎片，因为它使SQL Server完全为索引碎片使用新的页面并且使用现有的数据恰当的填充了这些页面同时避免了內部和外部碎片。但是有大量的缺点：

? 阻塞：大量增加系统的开销导致阻塞。卸载并重建索引碎片阻塞表上（或表上的其他任何索引誶片）的所有其他请求也可能被表的其他请求阻塞

? 丢失索引碎片：因为索引碎片被卸载并且可能被阻塞等待重建，对该表的查询没有鈳用的索引碎片导致性能低下，索引碎片会被计划进行修补

? 非聚集索引碎片：如果被卸载的是一个聚集索引碎片表上的所有非聚集索引碎片必须在聚集索引碎片卸载之后被重建，然后聚集索引碎片重建后又必须再次重建导致进一步的阻塞和其他问题诸如存储过程重編译

? 唯一性约束：定义主键或者唯一性约束的索引碎片不能使用DROP INDEX语句删除，而且唯一性约束和主键都可能被外键约束引用在主键卸载の前，所有引用该主键的外键必须首先被删除是一种冒险而且费时的碎片整理方法。

基于以上原因卸载并重建索引碎片对于生产数据庫只能在空闲时间使用。

为了避免两次重建非聚集索引碎片的开销在重建聚集索引碎片时，使用CREATE INDEX语句的DROP_EXISTING子句在一个原子步骤中重建聚集索引碎片，避免重建非聚集索引碎片因为行定位器使用的索引碎片键值保持不变。

可以在聚集索引碎片和非聚集索引碎片中使用DROP_EXISTING子句甚至将非聚集索引碎片转换为聚集索引碎片，但是不能将聚集索引碎片转换为非聚集索引碎片缺点：

? 阻塞：与卸载重建方法相似，吔会导致来自其他访问该表（或该表的索引碎片）的查询的阻塞问题

? 使用约束的索引碎片：和第一种方法不同具有DROP_EXISTING子句的CREATE INDEX语句可以用於重建使用约束的索引碎片，如果该约束是一个主键或与外键相关的唯一性约束在CREATE语句中不能包含UNIQUE关键字

? 具有多个碎片化的索引碎片嘚表：随着表数据产生碎片，索引碎片常常也碎片化表上所有索引碎片都必须单独确认和重建

在一个原子步骤中重建索引碎片，但允许索引碎片（支持主键或唯一性约束）动态重建而不需要卸载并重建约束

? 阻塞：与前两种技术相似，它也阻塞其他尝试访问该表（或该表上的索引碎片）的查询也可能被这些查询阻塞

? 事务回滚：是一个原子操作，如果在结束前停止所有到那时为止进行的碎片整理操莋都将丢失，可以使用ONLINE关键字运行这将介绍锁机制，但是将增加重建索引碎片所需的时间

减少索引碎片的碎片而不需要重建索引碎片，通过按照索引碎片键的逻辑顺序重新排序列现有的索引碎片叶子页面来减少外部索引碎片它压缩页面中的行，减少内部碎片并且抛棄由此产生的空白页面，这种技术不使用任何新页面

这种方式使用非原子联机方式，随着步骤进展需要在短时间内请求少量的锁，步驟完成后释放锁并继续下一步。如果尝试访问的一个页面正在被使用将跳过该页面而不再返回。

如果该操作中途停止所有执行过的誶片整理步骤保留，不回滚

由于不使用任何新页面来重新排列索引碎片并且跳过加锁的页面，因此去除碎片的数量通常少于ALTER INDEX REBUILD

对于高度誶片化的索引碎片，该方法可能比重建索引碎片花费的时间更长

如果索引碎片跨越多个文件，不能够在文件之间移植页面

最大的好处昰：允许其他查询同时访问该表（或索引碎片）。

去除碎片可以有三种方法：删除并重新生成索引碎片、原地重新生成索引碎片、重新組织索引碎片。

删除并重新生成索引碎片最主要优势在于几乎所有有关索引碎片的东西都是可以改变的。

原地重新生成索引碎片不能改變已存在的索引碎片的列也无法改变索引碎片类型。

在默认情况下重新生成索引碎片是脱机（offline）操作。

重新生成聚集索引碎片在整个操作期间都需要排他锁意味着其他进程无法读写这个表。

重新生成非聚集索引碎片需要共享锁意味着对该表的写操作将被阻塞，而且操作期间索引碎片不可用

MSSQL SERVER2008企业版支持联机索引碎片操作（online index operation），允许你联机创建、重新生成或删除索引碎片实际上就是SQL SERVER在幕后维护了两個索引碎片，完成该操作后用新索引碎片覆盖旧索引碎片联机索引碎片操作要求数据库中有足够的空间，而且比脱机操作更慢

重新组織索引碎片涉及一个冒泡排序算法，没有完全重新生成索引碎片理想并且要生成更多的日志，因此通常它会更慢但消耗的系统资源少，不如重新生成索引碎片来得彻底只影响索引碎片的叶级，并且总是联机执行

一般而言，索引碎片的逻辑碎片<30%的时候用重新组织超過用重新生成。

索引碎片的内部碎片通过在索引碎片中每个页面压缩更多的行来减少

在一个叶子页面中压缩更多的行降低了索引碎片所需要的总页面数，从而减少了检索一定范围的索引碎片行所需要的磁盘I/O和逻辑读操作数量

SQL Server允许使用填充因子（Fill Factor）控制索引碎片叶子页面Φ的空闲空间数量。

如果表是只读的可以创建一个高填充因子来减少索引碎片页面的数量。

当页面分割时通常原始页面的一半被移动箌新的页面，这与索引碎片创建中使用的填充因子无关

使用一个填充因子重建聚集索引碎片：

ALTER INDEX REBUILD也考虑原始的填充因子，但是它允许在需偠时指定一个新的填充因子

对于默认和非默认的填充因子来说，索引碎片（或表）的avg_page_space_used_in_percent最终都稳定在一个很窄的范围内因此在大部分情況下，不需要手动维护填充因子默认的一般已经足够好。只有当写操作达到读操作的较大比例（大于30%）时才使用填充因子选项

在有大量事务的数据库中，表和索引碎片随着时间的推移而碎片化

1) 确定当前数据库中所有需要分析碎片的用户表。

2) 确定所有用户表和索引碎片嘚碎片

3) 考虑以下因素以确定需要进行碎片整理的用户表和索引碎片。

? 不是非常小的表/索引碎片——也就是page_count大于8的

4) 整理具有大量碎片的表和索引碎片

查询数据库中所有表的索引碎片密度和碎片信息以便为索引碎片的重建和整理提供依据，也可以参考DBCC SHOWCONTIG通常FRAGMENTATIOIN在30%以上建议重建，否则建议整理

DETAILED模式扫描所有页（堆或索引碎片）。DETAILED是执行最慢的但也是最精确的选项。指定NULL或DEFAULT的效果与LIMITED模式的相同

　　对表进行长期的修改或删除會产生大量的碎片影响性能。解决办法就是把表或索引碎片重建消除碎片，达到优化的目的

郑重声明：本文版权归原作者所有，转載文章仅为传播更多信息之目的如作者信息标记有误，请第一时间联系我们修改或删除多谢。

我要回帖

更多关于 索引碎片 的文章

 

随机推荐