我正在使用 Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64) Feb 15 2020 01:47:30 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3（构建 9600：）
我在一个 2.5 TB 的数据库上有一些非常大的表（这些表本身可以超过 700GB）。
我一直在使用一些脚本进行索引维护。现在我正在做：
- 如果碎片 > 10% 则重组
- 如果碎片> 50％，则重建。
它在大多数情况下都可以正常工作，但对于我的 700gb 或更大的表，我认为 10% 将是一个很难达到的百分比。我想知道我是否应该降低那些大桌子的百分比，或者将它留在那个阈值是否可以。
我必须补充一点，我的服务器有 SSD 驱动程序，但只有 128 GB 的 RAM，因为它是标准版。因此，在大型查询（如报告）的情况下，表不可能适合 RAM，它必须扫描/查找索引。
我不想因为碎片而遇到 665 错误文件系统限制。 https://learn.microsoft.com/en-ie/troubleshoot/sql/admin/1450-and-665-errors-running-dbcc （我开始向数据库添加文件组以避免该错误，因为我' m 偶尔在属于主文件组的那些大表上使用它。）
那么我应该对非常大的表进行索引维护的自定义百分比吗？还是应该没问题？
这实际上取决于您的表的事务性。如果它们经常被更新和插入，你肯定会达到 10%。如果您没有达到 10%，那么降低到 5% 可能甚至不值得，因为这意味着您的表已经相当完好。
我亲自在只有 16 GB RAM 的服务器上开发了一个与您的示例非常相似的数据库，也是 SQL Server 2016 标准。我们的数据库是相当事务性的（每隔几分钟添加大约 1,000 条新记录），我们每晚都达到 10% 的重组阈值。因为操作非常繁重并且需要一段时间，我实际上做了相反的事情，并将我们更大的表索引的重组碎片阈值提高到 20%。事实证明，这对我们的业务来说要好得多，因为性能差异可以忽略不计，并且通常允许较大的表在周末之前不进行重组。
担心索引重组，甚至重建，是需要优化的事情的低端。甚至布伦特奥扎尔也说不用担心。:)
虽然我同意@BrentOzar 所说的，但我也同意这是一个特殊情况。这个问题是相关的，因为您通常不处理 700Gb 表。
在我看来，你应该：
这就是为什么我觉得你的问题非常中肯。我相信我们将进入一个越来越多的数据库迟早会有 TB 级表的世界。
数据的增长速度超过了我们对它的适应速度，我们没有处理此类问题的工具。