如果我执行以下操作：
SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent as avg,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID('dbname'), 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('dbname')
ORDER BY indexstats.avg_fragmentation_in_percent desc
它显示了碎片级别。然后我运行了 Ola Hallengren 的索引优化脚本，它明显减少了索引。
如果我再次运行查询，它现在会在没有索引的表中显示高碎片，例如：
Schema Table Index alloc_unit_type_desc avg page_cont
dbo tablename NULL IN_ROW_DATA 99.4362934362934 8176
我应该担心这些吗？
有什么我能做的吗？
有什么我应该做的吗？
我们遇到了性能问题。我知道 2008 年并不理想，正在解决这个问题。
数据文件也显示为 220gb，但实际使用的空间为 140gb。
Ola Hallengren 的索引优化脚本不执行堆碎片整理。
换句话说，在运行过程时不会发生表重建，这是预期的。
您可以运行
ALTER TABLE dbo.tablename REBUILD;以消除碎片。这也会重建堆上的非聚集索引。
比重建堆表更好的选择
您必须问问自己或应用程序团队为什么不能将聚集索引添加到表中。因为重建堆使用大量资源并且是临时解决方案。
如果您添加聚集索引，该索引将包含在索引优化脚本中，并且在脚本运行时将删除碎片。
另一种选择是添加聚集索引，不再担心索引碎片。
可能是因为堆表中的转发记录，但在 8167 页我会说这不太可能。一个起点可能是查看您的服务器上正在执行的查询。
SP_BlitzCache可以帮助您找到性能最差的查询。
这应该不是问题。除了磁盘空间，你不应该太担心。你不依赖自动增长，这是一件好事。