重组或重建索引后碎片率一直不变
有些数据表对索引采取了以下操作，可是碎片率就一直不变,avg_fragmentation_in_percent值就是不变：
1)重组或重建，删掉再重建;
2)更新统计信息；
3)将数据表删掉重建表和索引，再insert。
请问是怎么回事？
------最佳解决方案--------------------
avg_fragmentation_in_percent的值是多少？
------其他解决方案--------------------
你的数据量有多少？
莫非是几十条或者几百条数据？
因为数据量小的时候，数据分布在混合区，重建或者重新生成索引，数据密度是不会变化的
除非数据量大的时候才有效。

------其他解决方案--------------------
整理碎片，(从性能上说)对于小表基本上无效
------其他解决方案--------------------
87.5

引用:

avg_fragmentation_in_percent的值是多少？

------其他解决方案--------------------
87.5

引用:

avg_fragmentation_in_percent的值是多少？

------其他解决方案--------------------
很多表有这个情况，所以各种值都有。

引用:

87.5
引用:
avg_fragmentation_in_percent的值是多少？

------其他解决方案--------------------
减少索引中的碎片
 当索引分段的方式导致碎片影响查询性能时，有三种方法可减少碎片：
 
 删除并重新创建聚集索引。
 
 重新创建聚集索引将对数据进行重新分布，从而使数据页填满。填充度可以使用 CREATE INDEX 中的 FILLFACTOR 选项进行配置。这种方法的缺点是索引在删除和重新创建周期内为脱机状态，并且操作属原子级。如果中断索引创建，则不能重新创建索引。有关详细信息，请参阅 CREATE INDEX (Transact-SQL)。
 
 
 使用 ALTER INDEX REORGANIZE（代替 DBCC INDEXDEFRAG）按逻辑顺序重新排序索引的叶级页。由于这是联机操作，因此在语句运行时仍可使用索引。中断此操作时不会丢失已经完成的任务。此方法的缺点是在重新组织数据方面不如索引重新生成操作的效果好，而且不更新统计信息。
 
 
 使用 ALTER INDEX REBUILD（代替 DBCC DBREINDEX）联机或脱机重新生成索引。有关详细信息，请参阅 ALTER INDEX (Transact-SQL)。
 
 
 不需要仅因为碎片的原因而重新组织或重新生成索引。碎片的主要影响是，在索引扫描过程中会降低页的预读吞吐量。这将导致响应时间变长。如果含有碎片的表或索引中的查询工作负荷不涉及扫描（因为工作负荷主要是单独查找），则删除碎片可能不起作用。有关详细信息，请参阅此 Microsoft 网站。
 
 
------其他解决方案--------------------
 按照你这样理解，好像是说得通，呵呵。

引用:

你的数据量有多少？
莫非是几十条或者几百条数据？
因为数据量小的时候，数据分布在混合区，重建或者重新生成索引，数据密度是不会变化的
除非数据量大的时候才有效。