一：概述
在SQLServer中，存储数据的最小单位是页，每一页所能容纳的数据为8060字节.而页的组织方式是通过B树结构。在聚集索引B树中，只有叶子节点实际存储数据，
而其他根节点和中间节点仅仅用于存放查找叶子节点的数据.每一个叶子节点为一页，每页是不可分割的. 而SQLServer向每个页内存储数据的最小单位是表的行(Row).
当叶子节点中新插入的行或更新的行使得叶子节点无法容纳当前更新或者插入的行时，分页就产生了.在分页的过程中，就会产生碎片.
二：碎片相关知识
1、查询指定表的所有索引的碎片信息
SET NOCOUNT ON
USE test
DBCC SHOWCONTIG(TableForTest) WITH ALL_INDEXESDBCC SHOWCONTIG 正在扫描 'TableForTest' 表...
表: 'TableForTest' (709577566)；索引 ID: 1，数据库 ID: 7
已执行 TABLE 级别的扫描。
- 扫描页数................................: 1627
- 扫描区数..............................: 207
- 区切换次数..............................: 1523
- 每个区的平均页数........................: 7.9
- 扫描密度 [最佳计数:实际计数].......: 13.39% [204:1524]
- 逻辑扫描碎片 ..................: 99.08%
- 区扫描碎片 ..................: 1.45%
- 每页的平均可用字节数.....................: 3749.5
- 平均页密度(满).....................: 53.68%
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。
扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。
扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。
每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。
扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。
逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。
扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。
每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。
平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。
2、外部碎片与内部碎片
=>内部碎片，又称为平均页密度。是指索引正在占有超过它实际所需的空间大小。它具有两面型：低百分比会对读取数据的查询产生负面影响，会涉及更多读取操作，因为如果页被填充满的话，只需读取更少的页；另一方面，如果如果在创建索引时设置一个较低的填充因子，就可以避免当插入更多记录而不必进行页拆分。
=>外部碎片，又称平均碎片百分比，或逻辑碎片。是指在分页的逻辑顺序与物理顺序不匹配或者索引拥有的扩展不
连续时产生。包括以下两种：
逻辑碎片：这是索引的叶级页中出错页所占的百分比。出错页是指在IAM 中所指示的下一页不同于由叶级页中的下一页指针所指向的页。
区碎片（有的书翻译成：扩展碎片）：这是堆的叶级页中出错区所占的百分比。出错区是指：包含堆的当前页的区不是物理上的包含前一页的区后的下一个区。
这种碎片对索引的有序扫描操作具有非常显著的影响。它会对那些不依赖于索引链接的列表的操作（例如：查找操作，lookup操作，无序扫描）不产生影响。
对应sys.dm_db_index_physical_stats的列avg_fragmentation_in_percent 。因此为了获得最佳性能，avg_fragmentation_in_percent 的值应尽可能接近零。
但是，从0 到10％范围内的值都可以接受。所有减少碎片的方法（例如重新生成、重新组织或重新创建）都可用于降低这些值。
3、解决碎片问题：
=>删除索引并重建
这种方式并不好.在删除索引期间，索引不可用.会导致阻塞发生。而对于删除聚集索引，则会导致对应的非聚集索引重建两次(删除时重建，建立时再重建).虽然这种方法并不好，但是对于索引的整理最为有效
=>使用DROP_EXISTING语句重建索引
为了避免重建两次索引，使用DROP_EXISTING语句重建索引，因为这个语句是原子性的，不会导致非聚集索引重建两次，但同样的，这种方式也会造成阻塞
=>如前面文章所示，使用ALTER INDEX REBUILD语句重建索引
使用这个语句同样也是重建索引，但是通过动态重建索引而不需要卸载并重建索引.是优于前两种方法的，但依旧会造成阻塞。可以通过ONLINE关键字减少锁，但会造成重建时间加长.
=>使用ALTER INDEX REORGANIZE
这种方式不会重建索引，也不会生成新的页，仅仅是整理，当遇到加锁的页时跳过，所以不会造成阻塞。但同时，整理效果会差于前三种.
4、填充因子：
重建索引固然可以解决碎片的问题.但是重建索引的代价不仅仅是麻烦，还会造成阻塞。影响使用.而对于数据比较少的情况下，重建索引代价并不大。而当索引本身超过百兆的时候。重建索引的时间将会很让人蛋疼.
填充因子的作用正是如此。对于默认值来说，填充因子为0（0和100表示的是一个概念）,则表示页面可以100%使用。所以会遇到前面update或insert时，空间不足导致分页.通过设置填充因子，可以设置页面的使用程度:
如何设置填充因子的值
如何设置填充因子的值并没有一个公式或者理念可以准确的设置。
使用填充因子虽然可以减少更新或者插入时的分页，但同时因为需要更多的页，所以降低了查询的性能和占用更多的磁盘空间.
如何设置这个值进行trade-off需要根据具体的情况来看.
具体情况要根据对于表的读写比例来看,我这里给出我认为比较合适的值:
1.当读写比例大于100：1时，不要设置填充因子，100%填充
2.当写的次数大于读的次数时，设置50%-70%填充
3.当读写比例位于两者之间时80%-90%填充
三、案例分析
第一步：创建表、索引、初始化数据
--创建测试表
create table TableForTest(
col1 int,
col2 char(999),
col3 varchar(10)
)
--创建聚集索引
create clustered index cix on TableForTest(col1)
--插入8条数据
declare @var int
set @var = 100
while(@var < 900)
begin
insert into TableForTest(col1,col2,col3)
values(@var,'xxx','')
set @var = @var + 100
end
第二步：查看索引情况
select page_count,
avg_page_space_used_in_percent,
avg_fragmentation_in_percent
from sys.dm_db_index_physical_stats(db_id(),object_id('dbo.TableForTest'),null,null,'sampled')
或者
SET NOCOUNT ON
USE test
DBCC SHOWCONTIG(TableForTest) WITH ALL_INDEXES
可以看到，8条数据，正好存储在一个页上，没有外部碎片。
第三步：更新cols3，超出一页的存储范围(8060字节)
update TableForTest set col3 = 'abcd' where col1 = 800第四步：再次查看索引情况
可以看到，当数据大小超过一个页的容量8060字节，就会分页，生成第二页，并且产生内部碎片和外部碎片。
第四步：插入更多数据
--插入更多数据，执行三次
declare @var int
set @var = 100
while(@var < 1000)
begin
insert into TableForTest(col1,col2,col3)
values(@var,'xxx','')
set @var = @var + 1
end
可以查询碎片很多了。
第五步：重建索引对比情况
set statistics io on
select * from TableForTest
alter index cix on TableForTest rebuild
select * from TableForTest
set statistics io off
重建索引后对比，逻辑读取次数明显减少，碎片被清理。
我在微信订阅号等你！
