我们正在讨论是否对我们的 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 服务器将用于tempdb分配临时空间，而不是在正在重建索引的用户数据库中分配空间。这意味着您在索引重建操作期间将需要更少的用户数据库中的可用空间，而在 tempdb 中需要更多的可用空间。当 tempdb 位于与用户数据库不同的一组磁盘 (LUN) 上时，它会为您提供更好的优势。
从SORT_IN_TEMPDB 选项 - BOL：
确保在 SORT_IN_TEMPDB 为 ON 时阅读磁盘空间要求。
你知道痛点。您为什么不与您的 SAN 管理员一起修复它？配置错误和/或缓慢的 SAN 会导致各种问题，例如速度缓慢。
需要注意的一些要点：
是的，您必须在使用和不使用
SORT_IN_TEMPDB. 还要测量运行时间，在 PROD 中执行时，请确保在维护窗口或较少的服务器活动期间执行此操作。还要检查您的读/写数据和日志延迟。我不确定您是否有即时文件初始化，但它会在恢复、数据文件自动增长和创建新数据库时受益（仅提及完整性）。