在深入研究 Autogrowth 和围绕它的最佳实践（主要是主动并提前调整文件组大小）之后，有一个迫在眉睫的问题，我似乎没有找到一个彻底的答案。大多数文章，包括 TechNet，总是提到将 Autogrowth 设置为 10-15% 作为故障保险的做法。似乎很少提及将 MB 增长选项用作故障保险。
例如，假设您当前的数据库大小为 500GB，文件增长大约为每天约 1GB，给或取几百 MB。每个周末，您将必要的文件组调整 X 数量以应对增长——比如将其提高到 540GB 以应对近一个月的增长。如果在达到 540GB 后您无法对其进行调整（只是忘记了，意外的表扩展等），MSSQL 将开始行动并尝试将数据库增长 15%，但由于增长量而导致持续超时太大，服务器无法自动处理。这会导致应用程序超时，因此无论如何都需要手动干预。
我提出这个是因为在测试中，Autogrowth by percent 似乎在这些测试用例中提供了超时。但是，如果我将 Autogrowth 设置为一组 MB，例如 1,000MB，它会毫无问题地增长并且会及时增长。
所以总结一下我的问题，为什么文章（至少我读过的文章）会注意在没有发生主动手动文件增长的情况下使用按百分比自动增长而不是按 MB 自动增长的做法？在我看来，在测试和理论上，您更希望 Autogrow 调整设定的 MB 量。
我的这种想法是错误的，还是我只是读错了东西？很高兴听到你们在这里使用什么类型的管理技术。
谢谢！
我认为您在阅读错误的内容。由于您提到的原因，SQL Server 专业人士的普遍共识是使用以兆字节为单位的固定大小的自动增长。在这种情况下，我会忽略 TechNet。
这是一篇关于该主题的相关文章，尽管它旨在回答 sp_Blitz 中的一个发现。