重建索引时何时使用sort_in_tempdb？

我们正在讨论是否对DW表使用SORT_IN_TEMPDB选项。我的理解是，使用此选项时会有更多的写入，尽管它们的顺序更大。我们有一个SAN（众所周知，它有时速度很慢），因此在我们的情况下，我们希望尽可能地限制写入次数。我相信tempdb位于单独的LUN（磁盘集）上。

我们的数据文件和tempdb文件中都有足够的磁盘空间。在这种情况下，我们可以从使用SORT_IN_TEMPDB中受益吗？

令我震惊的是对此答案的评论

重建索引时，您将需要索引空间的两倍+ 20％进行排序。因此，通常来说，要重建数据库中的每个索引，您只需要数据库中最大索引的120％。如果您使用SORT_IN_TEMPDB，则只能赢20％，您的数据文件中仍然需要100％的附加收入。此外，在tempdb中使用sort会大大增加您的IO负载，因为您现在不再将索引一次写入数据文件，而是一次将其写入tempdb，然后再将其写入数据文件。因此，这并不总是理想的。

我们绝对不希望通过慢速/可能配置错误的SAN增加IO负载。

最好的测试方法是什么？通过简单地重建带有和不带有该选项的表并记录时间？

编辑：我们有8个tempdb文件，每个15GB。我们确实设置了TF 1117/1118标志，并且启用了IFI。当前，我们使用sort_in_tempdb选项（不带该选项）进行混合重建。

谢谢！

SQL Server 2012企业版

SORT_IN_TEMPDB意味着SQL Server将使用tempdb分配临时空间，而不是在正在重建其索引的用户数据库中分配空间。这意味着在进行索引重建操作期间，用户数据库中需要的可用空间更少，而tempdb中需要的可用空间更多。

当tempdb与用户数据库位于不同的磁盘（LUN）集上时，它可以为您提供更好的优势。

从SORT_IN_TEMPDB选项-BOL：

如果将SORT_IN_TEMPDB选项设置为ON，并且tempdb位于与目标文件组不同的一组磁盘上，则在第一阶段，数据页的读取与对tempdb中的排序工作区的写入发生在不同的磁盘上。这意味着磁盘对数据密钥的读取通常在磁盘上更多地连续进行，并且对tempdb磁盘的写入通常也是串行的，而建立最终索引的写入也是如此。即使其他用户正在使用数据库并访问单独的磁盘地址，指定SORT_IN_TEMPDB时的总体读写模式也比未指定时有效。

确保在SORT_IN_TEMPDB为ON时阅读磁盘空间要求。

慢速/可能配置错误的SAN

你知道痛点。您为什么不与SAN管理员合作进行修复？错误的配置和/或缓慢的SAN会引起诸如速度慢之类的问题。

注意事项：

• 进行联机索引重建时，请使用MAXDOP = 1-否则会导致碎片增加。
• 根据碎片级别和页面碎片智能地重组/重建索引。
• 阅读SQLFool 创建60 GB索引的经验
• 确保已正确配置tempdb- TF 1117（平等地增长文件组中的所有文件）和1118（仅充分扩展），并且具有更多的tempdb数据文件。

最好的测试方法是什么？

是的，在使用和不使用重建索引时，必须通过分析waitstats对其进行测试SORT_IN_TEMPDB。还要测量运行时间，在PROD中进行操作时，请确保在维护时段内或服务器活动较少时进行。还要检查您的读/写数据和日志延迟。

我不确定您具有即时文件初始化功能，但是在还原过程中，数据文件自动增长过程中以及创建新数据库时（出于完整性的考虑而提及），它都会有所帮助。