在SAN环境中对SQL索引进行碎片整理有什么好处？

我们的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/zh-cn/library/dd758814.aspx。最后但并非最不重要的一点是，使用磁盘管理器之类的第三方高级碎片整理程序。

请记住，仅建议将其用于NTFS类型的存储（例如Windows OS），这并不表示对任何产品的认可，我也不隶属于Condusiv Technologies或其子公司。