S. *_*mes 7 performance sql-server optimization clustered-index index-tuning
我们正在使用基于 SQL Server 2005 的专有应用程序，它有许多基于 HEAP 的表（即没有聚集索引）。多年来，这些表变得非常碎片化（例如 99% 碎片化）。我需要对它们进行碎片整理。
现在，在 SQL Server 2005 中，没有办法直接做到这一点。我可以：
现在，这是一个由供应商编写的大型应用程序——一个巨大的黑匣子。我并不急于弄乱他们的东西。我不太了解这些表是如何使用的。这样做的影响最小的方法是什么？
而且，作为后续：有许多这些基于 HEAP 的表，应用程序使用了十多个数据库。有没有办法自动选择 #2 或 #3？或者，我应该如何选择要修改的表？
更新：
回答（非常有帮助的）回复提出的问题：
简而言之，客户支持团队已经明确表示：您必须对表格进行碎片整理，如何做是您的事。
至于未来的版本：是的，新版本正在开发中，最终会迁移到 SQL Server 2012。但是他们今天需要性能解决方案。
最后，至于碎片整理时间太长：没关系。他们有 99% 碎片化的巨型表；该应用程序不在夜间使用；我可以轻松地一次花费数小时对它们进行碎片整理。
我将继续假设您已经确定了一个需要修复的问题……尽管我还不完全相信这一点。
与我在此处的回答类似，供应商应用程序有两种情况。
该应用程序当前已获得许可和/或供应商/所有者不希望您干预。
在这种情况下，绝对看不以任何方式更改架构，包括添加任何类型的索引。
进行架构更改实际上可能会使您的许可合同无效，但如果供应商决定在未来的架构更新中修复这些问题，这也会给供应商带来问题。从供应商的角度来看个人经验，我们有时不得不非常积极地告诉客户停止在我们的数据库中创建对象，因为这会影响我们成功应用架构更改的能力。（我不只是这么说 - 几个月前我们有一个案例，由于客户端创建的对象的意外依赖，一个客户端的架构更新失败。与添加索引略有不同的场景，但仍然，它确实出现了。）
在极少数情况下，数据库级别的更改没问题，但您需要绝对确定供应商对您计划做的事情没问题。
这种情况的最佳选择是……实际上，不要自己进行任何更改。整理一个令人信服的案例来证明为什么做出这些更改很重要，并将其提交给供应商，以便他们在未来的版本中实施。
从供应商的角度来看，理想情况下，建议是具体的，易于实施和测试，并对所有客户产生积极的影响。在大型应用程序中，建议将所有堆表转换为聚簇索引可能是（并且可能是）一个好主意，但它完全不是初学者。相反，找出前 5-10 个最重要的表格或 2-3 个应用领域，它们将从您的环境中的这种类型的变化中受益。
应用程序没有许可证或者供应商/所有者不关心你用它做什么。
在这种情况下，您可以添加任何您想要的索引，但对象应该保持在相同名称的位置（注意我没有说相同的对象）。这里有很多选项，具体取决于应用程序和数据库在内部的工作方式。如果您仍计划应用未来供应商提供的架构更改，请非常小心并确保为所有更改创建撤消脚本。
成功进行更改的关键是维护应用程序功能……说起来容易做起来难，当然，如果您计划进行重大更改。
也就是说，简单地添加聚集索引是非常安全的。挑战在于为每个索引选择合适的键，这应该手动完成，而不是自动完成。做好这部分工作的唯一方法是熟悉表的访问模式和目的。
想想看，您可以执行与其他情况相同的过程：确定 5-10 个具有最高整体影响的表，然后首先修复它们。您可能会发现这就是所有需要做的事情。
编辑：这个答案，在更一般的意义上，现在以视频形式提供。
碎片堆很重要。堆越大，遍历数据就越困难。性能受到影响。
如您所知，创建和删除 CI 将会对表中的行进行重新排序。如果供应商没有提供解决方案，而您有责任解决碎片问题，这正是我过去所做的。如果是我的话，我不会离开CI，我会放弃它。我会避免添加列，因为这会永久改变表的功能，并且如果您将 CI 保留在适当的位置，则可以提出相同的论点。
如果您这样做，请确保您有适当的存储空间来创建 CI，因为它将需要至少等于堆大小的存储空间，并且在执行此操作时还要考虑：您的服务级别要求。