金沙棋牌app手机下载

当前位置:金沙棋牌 > 金沙棋牌app手机下载 > 找出索引碎片,碎片查看与解决方案

找出索引碎片,碎片查看与解决方案

来源:http://www.logblo.com 作者:金沙棋牌 时间:2019-09-02 05:57

一.概述

    索引填充因子作用:提供填充因子选项是为了优化索引数据存储和性能。 当创建或重新生成索引时,填充因子的值可确定每个叶级页上要填充数据的空间百分比,以便在每一页上保留一些剩余存储空间作为以后扩展索引的可用空间,例如:指定填充因子的值为 80 表示每个叶级页上将有 20% 的空间保留为空,以便随着向基础表中添加数据而为扩展索引提供空间。

  填充因子的值是 1 到 100 之间的百分比,服务器范围的默认值为 0,这表示将完全填充叶级页。

 1.1 页拆分现象

   根据数据的查询和修改的比例,正确选择填充因子值,可提供足够的空间,以便随着向基础表中添加数据而扩展索引,从而降低页拆分的可能性。如果向已满的索引页添加新行(新行位置根据键排序规则,可以是页中任意行位置), 数据库引擎将把大约一半的行移到新页中,以便为该新行腾出空间。 这种重组称为页拆分。页拆分可为新记录腾出空间,但是执行页拆分可能需要花费一定的时间,此操作会消耗大量资源。 此外,它还可能造成碎片,从而导致 I/O 操作增加。 如果经常发生页拆分(可能过sys.dm_db_index_physical_stats 来查看页拆分情况),可通过使用新的或现有的填充因子值来重新生成索引,从而重新分发数据。

  填充值设置过低: 优点是 插入或修改时降低页的拆分次数。缺点是 会使索引需要更多的存储空间,并且会降低读取性能。

  填充值设置过高: 优点是 如果每一个索引页数据都全部填满,此时select效率最高。缺点是 插入或修改时需要移动后面所有页,效率低。

索引碎片:

索引已经是性能优化中大家常常提到而说到的问题,关于索引的很多的概念和解析,我们站点的索引进阶系列文章已经做了比较全面的讲述,我们这里就不在重复了。

一 . dm_db_index_physical_stats 重要字段说明

  1.1 内部碎片:是avg_page_space_used_in_percent字段。是指页的填充度,为了使磁盘使用状况达到最优,对于没有很多随机插入的索引,此值应接近 100%。 但是,对于具有很多随机插入且页很满的索引,其页拆分数将不断增加。 这将导致更多的碎片。 因此,为了减少页拆分,此值应小于 100%。

  1.2 外部碎片:也叫逻辑碎片是avg_fragmentation_in_percent字段。是分页的逻辑顺序和物理顺序不匹配或者索引拥有的扩展不连续时产生。当对表中定义的索引进行数据修改(INSERT、UPDATE 和 DELETE 语句)的整个过程中都会出现碎片。 由于这些修改通常并不在表和索引的行中平均分布,所以每页的填充度会随时间而改变。 对于扫描表的部分或全部索引的查询,这种碎片会导致额外的页读取。 这会妨碍数据的并行扫描。

  1.3 使用查看dm_db_index_physical_stats索引碎片 (SQL server 2005以上)。

SELECT OBJECT_NAME(sys.indexes.OBJECT_ID) AS tableName,
 sys.indexes.name,   
 page_count,
 (page_count*8.0)AS 'IndexSizeKB',
 avg_page_space_used_in_percent,
 avg_fragmentation_in_percent,
 record_count,avg_record_size_in_bytes,
index_type_desc,
fragment_count 
from sys.dm_db_index_physical_stats(db_id('dbname'),object_id('tablename'), null,null,'sampled') 
 JOIN sys.indexes  ON   sys.indexes.index_id = sys.dm_db_index_physical_stats.index_id
 AND sys.indexes.object_id = sys.dm_db_index_physical_stats.object_id

    下面还是接着上一篇查询PUB_StockCollect表下的索引

图片 1

  (1) avg_fragmentation_in_percent(外部碎片也叫逻辑碎片):最重要的列,索引碎片百分比。
    val >10% and val<= 30% -------------索引重组(碎片整理) alter index reorganize )
    val >30% --------------------------索引重建 alter index rebulid with (online=on)
    avg_fragmentation_in_percent:大规模的碎片(当碎片大于40%),可能要求索引重建
  (2) page_count:索引或数据页的总数。
  (3) avg_page_space_used_in_percent(内部碎片):最重要列:页面平均使用率也叫存储空间的平均百分比, 值越高(以80%填充度为参考点) 页存储数据就越多,内部碎片越少。
  (4) avg_record_size_in_bytes:平均记录大小(字节)。
  (5) index_type_desc列:索引类型-聚集索引或者非聚集索引等。
  (6) record_count:总记录数,相当于行数。
  (7) fragment_count: 碎片数。

二. 碎片与填充因子案例

   下面分析在生产环境下,对长时间一个表的ix_1索引进行分析。

-- 有一个PUB_Search_ResultVersions2表长期有增删改操作, 在很长一段时间运行后,查看碎片如下
dbcc SHOWCONTIG (PUB_Search_ResultVersions2,'ix_1')

  图片 2

    通过上图可以了解到平均页密度是29.74%,也就是内部碎片太多,现三个页的数据存储量才是正常一个页的存储量。扫描的页数是703页,涉及到了192个区。下面重新维护索引

--重建索引
ALTER INDEX ix_1 ON dbo.PUB_Search_ResultVersions2 REBUILD

  图片 3

     通过上图可以看到,扫描页数只有了248页(原来是703页) 用了36区(原来是192个区),现等于一页的实际数据是之前三页的总量, 查询将会减少了大量的I/O扫描。

  如果频繁的增删改,最好设置填充因子,默认是0,也就是100%, 如果有新索引键排序后,挤入到一个已填满8060字节的页中时,就会发生页拆分,产生碎片,这里我使用图形界面来设置填充因子为85%(最好通过t-sql来设置,做运维自动维护),再重建下索引使设置生效。

  图片 4

  下图可以看出平均页密度是85%,填充因子设置生效。可以在通过sys.dm_db_index_physical_stats重新查看该索引页使用数量。

图片 5

  • 内部碎片(或说叶级填充率):反映数据叶级的空间占用率或空闲率
  • 外部碎片:由于sqlserver以连续的8个page作为一个数据库块(区)extent作为读取单位,故此由于物理存储上的区和逻辑上不一致(不连续)而造成io读取切换

我们都知道,对于索引而言,我们会面临两个问题:

二. 解决碎片方法

-------------sqlserver 2000 碎片解决--------------
-- 索引重建 充填因子80
dbcc dbreindex(PUB_StockCategory,'PK_PUB_StockCategory',80)
-- 索引重组
DBCC INDEXDEFRAG(dbname,PUB_StockCategory,'PK_PUB_StockCategory')

 

------------sqlserver 2005以上碎片解决--------
-- 重新组织表中单个索引 
 ALTER INDEX ix_pub_stock_2 ON dbo.PUB_Stock REORGANIZE  
 -- 重新组织表中的所有索引
 ALTER INDEX ALL ON dbo.PUB_Stock REORGANIZE  
 -- 重新生成表中单个索引 (重点:重建索引用)
 ALTER INDEX ix_pub_stock_2 ON dbo.PUB_Stock REBUILD
 -- 重新生成表中的所有索引 
 ALTER INDEX ALL  ON dbo.PUB_Stock  
 REBUILD  WITH(FILLFACTOR=80, SORT_IN_TEMPDB=ON ,STATISTICS_NORECOMPUTE = ON )

 

1.是否建立了合适的索引

  • 逻辑碎片:这是索引的叶级页中出错页所占的百分比。对于出错页,分配给索引的下一个物理页不是由当前叶级页中的“下一页”指针所指向的页
  • 区碎片:这是堆的叶级页中出错区所占的百分比。出错区是指:包含堆的当前页的区不是物理上的包含前一页的区后的下一个区。(微软真不会解释概念:(

2.如何维护和诊断现有的索引

 

对于第一个问题,这确实不是三言两语可以讲清楚的,因为这首先需要对索引的知识掌握的非常清楚,而且还要知道建立索引的表中的数据的使用的情况(如读写的频率等)。我们会在之后的“收费阅读”版块,对索引进行深度的剖析,希望大家关注。

查询碎片情况:

对于第二个问题,我们首先就要清楚:索引建立之后不是一劳永逸的,而是需要不断的维护,而且数据库中的数据是变化的,所以,此时的索引可以不适合或者需要进行一些处理,如重组等。

  1.   dbcc showcontig:四部分对象名,【索引名】|【索引id】
  2.   dbcc showcontig:当前库对象id,【索引名】|【索引id】    
  3.   sys.dm_db_index_physical_stats:数据库id,对象id,索引id,分区id,扫描模式

我们接下来的几篇文章会探讨下面的问题:

      • 五个参数,基本上,【0(特殊的,index可以为0,故该处为-1)】|【null】|【default】 意义是一样的
  • 如何寻找索引碎片

  • ·使用填充因子

  • ·如何使用ReBuild来提高索引的效率

  • ·如何使用ReOrganize来提高索引的效率

  • ·如何找到缺失的索引

  • 如何找到无用的索引

  • ·如何找到高成本维护索引

  • ·如何使用索引视图提升性能

  • ·如何在计算列上面使用索引提升性能

 

 

基本指标:

 

  1. 扫描密度(%)[最佳计数:实际计数]:这是“最佳计数”与“实际计数”的比率。如果所有内容都是连续的,则该值为 100;如果该值小于 100,则存在一些碎片。“最佳计数”是指在一切都连续链接的情况下,区更改的理想数目。“实际计数”是指区更改的实际次数。
  2. 逻辑扫描碎片(%):扫描索引的叶级页时返回的出错页的百分比。此数与堆无关。对于出错页,分配给索引的下一个物理页不是由当前叶级页中的“下一页”指针所指向的页。
  3. 区扫描碎片(%):扫描索引的叶级页时出错区所占的百分比。此数与堆无关。对于出错区,包含当前索引页的区在物理上不是包含上一个索引页的区的下一个区。注意: 如果索引跨越多个文件,则此数字无意义。
  4. avg_page_space_used_in_percent:平均page空间使用率。相关的概念:页拆分、页填充率
  5. avg_fragment_size_in_pages:平均多少个page就有一个碎片,该值 越大越好
  6. avg_fragmentation_in_percent:碎片率,不解释。该值越小越好,和avg_fragment_size_in_pages 反比!
  7. page_count:扫描的总page数
  8. record_count:扫描的总记录数。注意:是相对于当前的扫描来说的记录数,不一定是你所认为的 用户表的一行数据
  9. forwarded_record_count:页拆分的记录数目

碎片类型简述

 

内部碎片

扫描方式

说到碎片,这里的话题其实就很广了。我们这里主要讨论索引的碎片,至于碎片是如何产生的,我们这里暂不做过多的深究,大家可以参看这篇文章:。对于索引而言,碎片分为两种“外部碎片”和“内部碎片”,我这里用两个图简单的介绍一下:

  索引、堆,因其本质为B数结构,B数是分层级的,故可以多种选择来扫描:非页级?or 仅取一代的样本?or 完全的扫描?

图片 6图片 7

 

 

函数的执行模式将确定为了获取此函数所使用的统计信息数据而执行的扫描级别。mode 被指定为 LIMITED、SAMPLED 或 DETAILED。该函数遍历分配单元的页链,这些分配单元构成表或索引的指定分区。sys.dm_db_index_physical_stats 只需要一个意向共享 (IS) 表锁,而忽略其运行所处的模式。有关锁定的详细信息,请参阅锁模式。

LIMITED 模式运行最快,扫描的页数最少。对于索引,只扫描 B 树的父级别页(即叶级别以上的页)。对于堆,只检查关联的 PFS 和 IAM 页;不扫描堆的数据页。在 SQL Server 2005 中,在 LIMITED 模式下扫描堆的所有页。

在 LIMITED 模式下,compressed_page_count 为 NULL,这是因为数据库引擎只能扫描 B 树的非叶页和堆的 IAM 和 PFS 页。使用 SAMPLED 模式可以获取 compressed_page_count 的估计值,使用 DETAILED 模式可以获取 compressed_page_count 的实际值。SAMPLED 模式将返回基于索引或堆中所有页的 1% 样本的统计信息。如果索引或堆少于 10,000 页,则使用 DETAILED 模式代替 SAMPLED。

DETAILED 模式将扫描所有页并返回所有统计信息。

从 LIMITED 到 DETAILED 模式,速度将越来越慢,因为在每个模式中执行的任务越来越多。若要快速测量表或索引的大小或碎片级别,请使用 LIMITED 模式。它的速度最快,并且对于索引的 IN_ROW_DATA 分配单元中的每个非叶级别,不返回与其对应的一行。

 

 

大家可以看到:索引结构的页中,有很多的页中都是没有被填充的,这或许是我故意特定的,如在索引重建重组的时候我们可以指定页面的填充因子,但是很多的时候,这确实我们没有觉察到的。因为我们很多时候都以为索引页是被填满的,但是随着数据的增删改的进行,索引页中就发生了上述的内部碎片。

 

外部碎片

最佳实践
请始终确保使用 DB_ID 或 OBJECT_ID 时返回了有效的 ID。例如,在使用 OBJECT_ID 时,请指定三部分的名称,如 OBJECT_ID(N'AdventureWorks2008R2.Person.Address'),或者在 sys.dm_db_index_physical_stats 函数中使用由函数返回的值之前对这些值进行测试。下面的示例 A 和 B 演示了一种指定数据库和对象 ID 的安全方法。

检测碎片
在对表进而对表中定义的索引进行数据修改(INSERT、UPDATE 和 DELETE 语句)的整个过程中都会出现碎片。由于这些修改通常并不在表和索引的行中平均分布,所以每页的填充度会随时间而改变。对于扫描表的部分或全部索引的查询,这种碎片会导致附加的页读取。从而延缓了数据的并行扫描。

SQL Server 2008 中的碎片计算算法比 SQL Server 2000 中的更精确。因此,碎片值显得更高。例如,在 SQL Server 2000 中,如果一个表的第 11 页和第 13 页在同一区中,而第 12 页不在该区中,该表不被视为含有碎片。但是访问这些页需要两次物理 I/O 操作,因此,在 SQL Server 2008 中,这将算作碎片。

索引或堆的碎片级别显示在 avg_fragmentation_in_percent 列中。对于堆,此值表示堆的区碎片。对于索引,此值表示索引的逻辑碎片。与 DBCC SHOWCONTIG 不同,这两种情况下的碎片计算算法都会考虑跨越多个文件的存储,因而结果是精确的。

逻辑碎片 
这是索引的叶级页中出错页所占的百分比。对于出错页,分配给索引的下一个物理页不是由当前叶级页中的“下一页”指针所指向的页。

区碎片 
这是堆的叶级页中出错区所占的百分比。出错区是指:包含堆的当前页的区不是物理上的包含前一页的区后的下一个区。

为了获得最佳性能,avg_fragmentation_in_percent 的值应尽可能接近零。但是,从 0 到 10% 范围内的值都可以接受。所有减少碎片的方法(例如重新生成、重新组织或重新创建)都可用于降低这些值。有关如何分析索引中碎片程度的详细信息,请参阅重新组织和重新生成索引。

减少索引中的碎片
当索引分段的方式导致碎片影响查询性能时,有三种方法可减少碎片:

1、删除并重新创建聚集索引。
重新创建聚集索引将对数据进行重新分布,从而使数据页填满。填充度可以使用 CREATE INDEX 中的 FILLFACTOR 选项进行配置。这种方法的缺点是索引在删除和重新创建周期内为脱机状态,并且操作属原子级。如果中断索引创建,则不能重新创建索引。有关详细信息,请参阅 CREATE INDEX (Transact-SQL)。

2、使用 ALTER INDEX REORGANIZE(代替 DBCC INDEXDEFRAG)按逻辑顺序重新排序索引的叶级页。由于这是联机操作,因此在语句运行时仍可使用索引。中断此操作时不会丢失已经完成的任务。此方法的缺点是在重新组织数据方面不如索引重新生成操作的效果好,而且不更新统计信息。


3、使用 ALTER INDEX REBUILD(代替 DBCC DBREINDEX)联机或脱机重新生成索引。有关详细信息,请参阅 ALTER INDEX (Transact-SQL)。


不需要仅因为碎片的原因而重新组织或重新生成索引。碎片的主要影响是,在索引扫描过程中会降低页的预读吞吐量。这将导致响应时间变长。如果含有碎片的表或索引中的查询工作负荷不涉及扫描(因为工作负荷主要是单独查找),则删除碎片可能不起作用。有关详细信息,请参阅此 Microsoft 网站。
注意: 
如果在收缩操作中对索引进行部分或完全移动,则运行 DBCC SHRINKFILE 或 DBCC SHRINKDATABASE 可能产生碎片。因此,如果必须执行收缩操作,则不应在删除碎片后进行。



减少堆中的碎片
若要减少堆的区碎片,请对表创建聚集索引,然后删除该索引。在创建聚集索引时将重新分布数据。同时会考虑数据库中可用空间的分布,从而使其尽可能优化。当删除聚集索引以重新创建堆时,数据不会移动并保持最佳位置。有关如何执行这些操作的信息,请参阅 CREATE INDEX 和 DROP INDEX。

压缩大型对象数据
默认情况下,ALTER INDEX REORGANIZE 语句将压缩包含大型对象 (LOB) 数据的页。因为不会释放空的 LOB 页,所以在删除大量 LOB 数据或 LOB 列时,压缩此数据可改善磁盘空间使用情况。

重新组织指定的聚集索引将压缩聚集索引中包含的所有 LOB 列。重新组织非聚集索引将压缩作为索引中非键(已包括)列的所有 LOB 列。如果语句中指定 ALL,则将对与指定表或视图关联的所有索引进行重新组织。此外,将压缩与聚集索引、基础表或带有包含列的非聚集索引关联的所有 LOB 列。

评估磁盘空间使用状况
avg_page_space_used_in_percent 列指示页填充度。为了使磁盘使用状况达到最优,对于没有很多随机插入的索引,此值应接近 100%。但是,对于具有很多随机插入且页很满的索引,其页拆分数将不断增加。这将导致更多的碎片。因此,为了减少页拆分,此值应小于 100%。使用指定的 FILLFACTOR 选项重新生成索引可以改变页填充度,以便符合索引中的查询模式。有关填充因子的详细信息,请参阅填充因子。此外,ALTER INDEX REORGANIZE 还试图通过将页填充到上一次指定的 FILLFACTOR 来压缩索引。这会增加 avg_space_used_in_percent 的值。请注意,ALTER INDEX REORGANIZE 不会降低页填充度。相反,必须执行索引重新生成。

评估索引碎片
碎片由分配单元中同一文件内的物理连续的叶级页组成。一个索引至少有一个碎片。索引可以包含的最大碎片数等于索引的页级别页数。碎片越大,意味着读取相同页数所需的磁盘 I/O 越少。因此,avg_fragment_size_in_pages 值越大,范围扫描的性能越好。avg_fragment_size_in_pages 和 avg_fragmentation_in_percent 值成反比。因此,重新生成或重新组织索引会减少碎片数量,但同时增大碎片大小。

所谓的外部碎片,其实这就和索引结构的底层的物理存储相关了。我们上面看到的索引结构,其实就是索引的一个逻辑视图,因为实实在在的索引结构中的页的保存在物理存储上面是这样的:如图:

 

图片 8

 

 

 

 

也就说,索引的数据会保存在一块存储空间里面,但是,这块存储空间同时也为其他的结构保存数据,如表,其他的索引等。所以,对一个某个索引,如A而言,那么,它所包含的页的存储的地址可能就不是连续的,如上图所示,里面标红的两个存储位置就是其他的对象的。但是,数据库在读取存储系统上面的数据的时候,是每次都会去读取连续的空间,而不是跳跃性的读取,如上面的,要读取A索引的全部数据,那么上面存储空间中两个标红的空间的数据也会被读取,这就是说:读取了我们原本不应该读取的数据。其实这一点,大家完全可以结合我们平时所知道的磁盘的碎片来理解。

 

 

下面我们就来看看如何来找碎片:

 

查找索引碎片

 

其实,在查找过程中,我们主要是依赖sys.dm_db_index_physical_stats这个动态管理函数。

 

内部碎片

 

下面,就给出查找内部碎片的查询,其实原理非常的简单,主要就是看页面空间的使用百分比,然后加上一些经验值的过滤添加,如下:

 

EXEC sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
DECLARE @DefaultFillFactor INT 
DECLARE @Fillfactor TABLE(Name VARCHAR(100),Minimum INT ,Maximum INT,config_value INT ,run_value INT)
INSERT INTO @Fillfactor EXEC sp_configure 'fill factor (%)' 
SELECT @DefaultFillFactor = CASE WHEN run_value=0 THEN 100 ELSE run_value END FROM @Fillfactor 

SELECT
DB_NAME() AS DBname,
QUOTENAME(s.name) AS CchemaName,
QUOTENAME(o.name) AS TableName,
i.name AS IndexName,
stats.Index_type_desc AS IndexType,
stats.page_count AS [PageCount],
stats.partition_number AS PartitionNumber,
CASE WHEN i.fill_factor>0 THEN i.fill_factor ELSE @DefaultFillFactor END AS [Fill Factor],
stats.avg_page_space_used_in_percent,
CASE WHEN stats.index_level =0 THEN 'Leaf Level' ELSE 'Nonleaf Level' END AS IndexLevel
FROM 
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL , NULL, 'DETAILED') AS stats,
sys.objects AS o,
sys.schemas AS s,
sys.indexes AS iWHERE 
o.OBJECT_ID = stats.OBJECT_ID AND s.schema_id = o.schema_id AND i.OBJECT_ID = stats.OBJECT_ID AND i.index_id = stats.index_idAND stats.avg_page_space_used_in_percent<= 85 AND stats.page_count >= 10 AND stats.index_id > 0 ORDER BY stats.avg_page_space_used_in_percent ASC, stats.page_count DESC

 

我常常在Where中加入很多的过滤添加,因为之前说过,如果单看原始的数据,没有多大的意义。在上述的查询中,我们只对那些有至少10个页以上的、页面空间使用率小于85%的索引感兴趣。我们在上述查询中重点关注的字段就是:avg_page_space_used_in_percent和PageCount。

一般而言,导致avg_page_space_used_in_percent偏低的原因如下:

由于页面分割和删除记录:在这种情况下,我们必须重建或重组的索引。如果碎片在非叶级的,重建需要减少碎片。

由于填充因子设置:内部的碎片,这是因为填充因子设置的填充因子值的索引错误的设定可能会导致内部碎片,我们必须重建索引选择新的填充因子值。

由于记录大小:一些数据记录可能导致页发生分裂。例如,我们假设一个记录的大小是3000字节,那么一个索引页只能容纳两个记录。第三个记录不能被安装到一个页面,在页面中剩余的可用空间小于3000个字节。在这种情况下,每一页都将有2060个字节的空的空间。要摆脱的碎片的大小的记录,我们可能需要重新设计表或做一个垂直分区的表。

 

 

外部碎片

 

EXEC sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
G
ODECLARE @DefaultFillFactor INT
DECLARE @Fillfactor TABLE(Name VARCHAR(100),Minimum INT ,Maximum INT,config_value INT ,run_value INT)
INSERT INTO @Fillfactor EXEC sp_configure 'fill factor (%)'
SELECT @DefaultFillFactor = CASE WHEN run_value=0 THEN 100 ELSE run_value END FROM @Fillfactor

SELECT
DB_NAME() AS DBname,
QUOTENAME(s.name) AS CchemaName,
QUOTENAME(o.name) AS TableName,
i.name AS IndexName,
stats.Index_type_desc AS IndexType,
stats.page_count AS [PageCount],
stats.partition_number AS PartitionNumber,
CASE WHEN i.fill_factor>0 THEN i.fill_factor ELSE @DefaultFillFactor END AS [Fill Factor],
stats.avg_fragmentation_in_percent,stats.fragment_count,
CASE WHEN stats.index_level =0 THEN 'Leaf Level' ELSE 'Nonleaf Level' END AS IndexLevel
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL , NULL, 'LIMITED') AS stats,
sys.objects AS o,
sys.schemas AS s,
sys.indexes AS iWHERE
o.OBJECT_ID = stats.OBJECT_ID AND s.schema_id = o.schema_id AND i.OBJECT_ID = stats.OBJECT_ID AND i.index_id = stats.index_idAND stats.avg_fragmentation_in_percent>= 20 AND stats.page_count >= 1000ORDER BY stats.avg_fragmentation_in_percent DESC,stats.page_count DESC

 

 

一般而言,导致avg_fragmentation_in_percent偏高的原因如下:  

SQL Server存储引擎从混合区为一个表或索引分配页,直到的表或索引的数据大小达到8个页.一旦它们的页面数达到8页之后,存储引擎开始就开始为它们后续的数据存储分配统一的数据块(extent),然后把数据放在数据块的页中。如果数据库中有很多的小的数据表,那么它们的页将会被放在混合块中,加入,有某个数据表的页有7个,那么可能这7个页被分别放在不同的块中,也就说,这些页之间在存储上面可能是完全不连续的,这将会导致很大的碎片。  

其他常见的原因是由于DML操作的页面拆分,而新分配的页和之前的页不在连续的存储空间中。

 

对于维护,给出以下建议:

  • 碎片率在20%至40%,重新组织索引碎片

  • 碎片率在40%以上,考虑重建索引

  • 对于那些索引结构中,页数少于1000的,可以暂时不维护

  • 如果有索引结构中页数超过5万,而且碎片率在10%和20%之间,也将被考虑重组。

 

本文由金沙棋牌发布于金沙棋牌app手机下载,转载请注明出处:找出索引碎片,碎片查看与解决方案

关键词:

上一篇:及使用考虑,nvarchar的区别浅析

下一篇:没有了