Answer 1

Answer 2

您声明您添加了聚簇索引以缓解表碎片，然后立即将其删除。

聚簇索引通过对群集密钥进行排序来删除碎片，但是您说该密钥将来无法使用。这引出了一个问题：为什么要使用这个密钥进行碎片整理？

创建此群集密钥并保留它是有意义的，因为您显然希望/需要以这种方式排序的数据。您说数据更改会导致数据移动处罚无法承担;您是否考虑过创建比默认值FILLFACTOR更低的索引？根据数据变化模式，您可以从低至80％的收益中受益。然后，每页有20％的“未使用”空间，但是当更改聚类键值时，页面拆分的好处就会增加。

这对你有帮助吗？

Answer 3

您可以通过运行DBCC SHRINKFILE with NOTRUNCATE.

来压缩堆

根据评论，我发现你没有使用渗透聚集索引进行测试。

为了正确看待这一点，我们拥有每天1000万个新行的数据库，并在所有表上使用聚簇索引。删除的“间隙”将通过预定的ALTER INDEX（以及前向指针/页面拆分）删除。

索引后你的12GB表可能是2GB：它只分配了12GB，但也是大量碎片。

Answer 4

我理解您受到传统设计设计约束的痛苦。

您是否有机会在另一台服务器上恢复相关表的备份并创建聚簇索引？如果在一组窄的唯一列或标识列上创建聚簇索引，则很可能会减少总表（数据和索引）的大小。

在我的一个遗留应用程序中，所有数据都是通过视图访问的。我能够修改基础表的模式，添加标识列和聚簇索引，而不会影响应用程序。

拥有堆的另一个缺点是与任何已转移的行相关联的额外IO。

当我被问到是否有任何证据证明我们需要永久保留在桌面上的clusted索引时，我发现以下文章有效

This article is by Microsoft

Answer 5

没有人在谈论的问题是硬盘驱动器上的数据或日志设备文件的碎片！每个人都在讨论索引的碎片化以及如何避免/限制碎片。

仅供参考：创建数据库时，您可以指定.MDF的INITIAL大小以及需要增长时的增长量。您对.LDF文件执行相同操作。没有任何保证，当这两个文件增加时，为所需的额外磁盘空间分配的磁盘空间将与分配的现有磁盘空间在物理上一致!!

每当这两个设备文件中的一个需要扩展时，硬盘驱动器磁盘空间就有可能碎片化。这意味着硬盘驱动器上的磁头需要更加努力（并花费更多时间）从硬盘驱动器的一个部分移动到另一个部分以访问数据库中的必要数据。这类似于购买一小块土地并建造一个适合该土地的房屋。当你需要扩建房屋时，除非你购买隔壁的空地，否则你没有更多土地可供使用 - 除非 - 如果其他人在此期间已经购买了这块土地并在其上建造房屋怎么办？然后你不能扩大你的房子。唯一的可能性是在“邻里”购买另一块土地并在其上建造另一栋房屋。问题变成了 - 你和你的两个孩子将住在A楼，而你的妻子和第三个孩子将住在B楼。这将是一种痛苦（只要你还在结婚）。

解决这种情况的解决方案是“购买更大的土地，拿起现有的房屋（即数据库），将其搬到更大的土地上，然后在那里扩建房屋”。那么 - 你如何用数据库做到这一点？执行完整备份，删除数据库（除非您有足够的可用磁盘空间来保留旧的碎片数据库 - 以防万一）以及新数据库），创建一个分配了大量初始磁盘空间的全新数据库（不保证操作系统将确保您请求的空间是连续的）然后将数据库还原到刚创建的新数据库空间。是的 - 这很痛苦，但我不知道任何可用于SQL数据库文件的“自动磁盘碎片整理程序”软件。