我正在使用这个 sproc 来重建和碎片整理。 它可以工作，但某些表仍然具有很高的碎片百分比。
Index alloc_unit_type_desc avg_fragmentation_in_percent page_count
PK_AccessPoint IN_ROW_DATA 33.3333333333333 3
这是指向 sproc 的链接
https://blogs.msdn.microsoft.com/azuresqldbsupport/2016/07/03/how-to-maintain-azure-sql-indexes-and-statistics/
为什么表平均碎片仍然为 33%？ 程序运行了多次。 其他表格为0%。 我根本不知道发生了什么。
查询索引和碎片：
SELECT dbschemas.[name] as 'Schema',
dbtables.object_id,
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID()
谢谢
对于小型表，通常无法检测到对碎片的性能影响。前 8 页分配将来自混合盘区，混合盘区可以位于数据库文件中的任何位置。重建索引不会改变这种性质。
如果表较小，则在碎片计算过程中，这些混合页的权重很大;因此，重建索引可能不会减少碎片。(事实上，我可以很容易地构建一个重建后碎片增加的情况。这些碎片不会对您的查询性能造成痛苦;所以基本上你可以忽略
即使在重建后，小索引仍然存在碎片的原因是，在重建后，分配给索引的页面来自混合范围。混合扩展数据块包含混合页面，扩展数据块是 8 个页面的集合，这些页面始终是数据库在需要页面写入信息时分配给数据库的前 8 个页面。前 8 页将始终来自混合范围，之后它将分配统一范围。从混合扩展数据块分配前 8 页的原因是数据库引擎假设其很可能的表很小(在开始时)，并且分配统一扩展数据块没有太大优势，因此它在内部决定从混合扩展数据块分配前 8 页。当超过 8 页限制时，它将开始分配统一扩展数据块。 由于混合扩展数据块未分配给任何特定的 IAM 链，这意味着它可能包含分配给可能 8 个独立 IAM 的页面。这是一个非常重要的事实。按混合范围分配的前 8 页可能分散在任何地方，这就是即使在重建后也会导致碎片的原因。
有关更多信息，请阅读本文。