我试图了解SQL Server Cumulative Updates的推荐最佳实践。
目前，我们的理念是“除非 CU 解决的问题是我们遇到的问题，否则什么也不做”。这适用于“如果它没有损坏，就不要修复它”的方法，但我想知道这是否真的是一个好主意，因为这么多 CU 都有性能增强。我们正在考虑在 CU 发布后的一两个月内将 CU 添加到我们定期维护周期中应用的补丁中。
其他人做什么，为什么？
作为对影响以下答案的问题的更新，2016 年 3 月 24 日，Microsoft 的 SQL Server 团队宣布他们正在更新其服务模型。Microsoft 建议所有用户安装 2016 年 1 月之后发布的所有 CU：
从 1 月份的 CU 版本开始，这些警告消息已更新，我们现在建议在 CU 可用时进行持续、主动的安装。在计划安装 CU 时，您应该与计划安装 SP（Service Pack）时一样有信心。这是因为 CU 已通过 SP 级别的认证和测试。此外，Microsoft CSS 数据表明，很大比例的客户问题通常以前在已发布的 CU 中得到解决，但并未主动应用。更重要的是，CU 包含了除修补程序之外的附加值。这些还可能包含增强整体体验的可支持性、日志记录和可靠性更新。
除了消息和指导更新之外，我们还对 CU 获取模型进行了更新。
收购变更：
- 当然，CU 传统上在“Hotfix”服务器上提供（伴随着与“QFE”或“Hotfix”相关的“警告性语言”）。这里的不一致之处在于 CU 不再是真正简单的快速修补程序。所包含的更新在当今的个人和完整系统集成级别上都经过了很好的测试。
- 因此，我们现在在 microsoft.com/downloads 上按照主流支持的基准（今天的 2012 SP2/SP3 和 2014 RTM/SP1）放置最新的 CU，就像今天为 Service Packs 所做的那样
- 此外，我们将很快将所有 CU 发布并维护到 Windows 更新目录中，以方便获取和分发
- 只有临时 CU 的“按需”修复将被放置在修补程序服务器上向前推进
- 为了减少摩擦，从 microsoft.com/downloads 下载 CU 不需要提供/接收电子邮件和 URL
- 我们还在评估提供最新的 CU 作为 Microsoft 更新的可选更新，就像今天的服务包一样
我大力提倡及时了解最新的累积更新，但前提是您的测试/QA 周期可以确保针对它进行全面和适当的回归测试。SQLskills的Glenn Berry也是这种方法的支持者。
Microsoft 自己的建议是仅应用修复影响您的问题的 CU，尽管他们最近放松了这种立场。问题是您可能会受到这些问题中的一个或多个的影响并且不知道它，或者即使它还没有影响到您，您明天也可能会受到影响。您是否要经历并尝试在您的分支的每个 CU 中重现每个修复背后的问题？您是否要连续执行此操作以确保您仍然不受影响？
老实说：我从来没有遇到过将任何 CU 应用到我的实例的问题。事实上，他们的 CU 发布过程比服务包发布周期可靠得多，并且在许多情况下（包括最近使用 SQL Server 2012 Service Pack 2），您不想在第一次之前应用服务包反正那个分支的 CU 已经发布了。在这种情况下，有一个临时修补程序可以解决未及时修复以制作 Service Pack 代码的问题，但这并不总是正确的。
我们过去常常跟上 CU 的步伐。发布后大约 1 个月，无论我们遇到的问题是否被他们纠正，我们都会应用它们。
然而，在我们遇到一个大问题后，我们停止了这种做法。在我们的案例中，我们安装的服务包修复了我们遇到的全文索引问题。几个月后，其中一个 CU回滚了该特定修复程序。这给我们带来了各种各样的问题，需要进行大量研究才能弄清楚发生了什么。我们最终编写了一个解决方法，后来当一个新的 CU 破坏了其他东西时，它被搞砸了……最终结果：服务器从头重新安装到特定的 SP/CU 级别并冻结。
我们的应用程序性能如此之高，以至于我们不关心可能出现的任何新的 SQL 性能增强，所以这不是问题。此外，报告和其他查询一直在撤回有效结果，因此不需要任何新的调整。这意味着在我们此时考虑应用 CU 之前，它必须是一个安全问题。
我完全同意 Aaron 的观点：只有在您的测试/QA 周期可以正确测试它的情况下才这样做 否则我会说要避开，除非它纠正了您实际面临的问题。即便如此，用真实数据测试它的每一个小方面，以确保它们不会破坏你可能依赖的东西。