我们的 SQL 服务器位于 SAN 上。它包含数十个 OLTP 数据库，其中一些包含多个包含超过 100 万条记录的表。
我们每周都运行Ola Hallengren 的索引维护脚本，每次运行几个小时。根据碎片阈值，脚本将重新组织或重新索引索引。我们观察到，在重新索引期间，日志文件会变得很大，这会导致日志传送期间过度消耗带宽。
然后是Brent Ozar 的一篇文章，他说不要再担心 SQL 索引了：
您的硬盘驱动器与同时发出驱动器请求的其他服务器共享，因此驱动器将始终在各处跳跃以获取数据。对索引进行碎片整理只是无意义的忙碌工作。
谷歌搜索这个问题会导致不同的意见，大多数支持似乎太简短或太弱的论点。我们的暂定计划是调整维护脚本中的碎片阈值，使其重组的频率远高于重新索引的频率。
最终判决是什么？考虑到与运行每周维护作业相关的负担，是否值得在 SAN 上对 SQL 索引进行碎片整理？
碎片整理策略有助于提高磁盘扫描速度。
各种各样的意见是因为环境的理想碎片整理策略应该取决于许多不同的因素。还有多个潜在的碎片层在起作用。
说您的数据库存储在 SAN 上是不够的信息。例如：
数据库文件是存储在不同的物理 RAID 组还是相同的 RAID 组中？同一设备上还有哪些其他进程处于活动状态？您的备份文件也结束了吗？您可能需要向您的 SAN 管理员询问此信息，因为它并不总是透明的。
数据库的访问模式是什么？OLTP 通常是随机访问，但有时应用程序对表扫描很满意，您无法更改其行为（ISV 应用程序）。应用程序是多读、多写还是介于两者之间？
在恢复/故障转移期间是否存在性能 SLA ？
Brent 的帖子假设有一个巨大的存储池并且所有东西都共享它。这意味着物理磁盘很少空闲，因此大多数访问都是随机的。如果这是你的情况，那么建议适用，我在很大程度上同意它。虽然这种类型的策略更易于管理，但它不一定是 (a) 您在您的环境中拥有什么，或者 (b) 什么是您的环境的最佳解决方案。
如果索引维护是繁重的，考虑不那么激进，和/或在一周内摊销成本（即，每天运行一次轻度维护，而不是每周一次的重度维护）。
您还可以打开该
SortInTempdb选项以潜在地减少用户数据库中发生的日志记录量。理想情况下，您应该只为那些需要注意的索引重新组织/重新索引，否则您会浪费资源并可能导致其他问题。
您需要建立一个性能基准，并且每当您进行更改时，将性能更改与基准进行比较，以确定您的更改是否值得实施。
好的，问题是关于数据库索引，它是一个文件或一组文件的构造。阅读上面的答案会让人相信我们谈论的是磁盘级别的碎片，而不是文件内部的索引。这些完全不同的主题。
这里的短视方法是在检索数据时的性能，并且如果索引被去碎片化或重建，OLTP 数据库会提高。答案是肯定的！但是，重要的是要注意磁盘碎片也是一个因素。
总体上最低的“成本”？进行数据库维护。成本第二低，分离数据库，将其移至其他位置，重新格式化磁盘并遵循磁盘分区对齐的最佳实践http://msdn.microsoft.com/en-us/library/dd758814.aspx。最后但同样重要的是，使用 Diskkeeper 之类的第 3 方高级碎片整理程序。
请记住，这仅推荐用于 NTFS 类型的存储（例如 Windows 操作系统），这不是对任何产品的认可，我也不隶属于 Condusiv Technologies 或其子公司。