SQL Server 2016：时态表性能与触发器和 CDC

Question

似乎很难找到系统版本化时态表与旧选项（例如 DB 触发器和 CDC）之间的比较。我目前没有时间在 SQL Server 2016 上编写扩展测试，所以我想我会在这里问一下。

基本上，触发器的典型优势是它们在独立和集群/alwaysOn 环境中更易于管理，可以实时同步，并且可以访问会话数据，例如用户 ID。

另一方面，CDC 虽然需要更多的管理并且是异步的，但要轻得多，因此性能要好得多。因此，如果对触发器引起的瓶颈可能成为问题有任何疑问，CDC 基本上将是最佳解决方案。在硬件要求方面，由于使用日志和 cdc 审计表来跟踪更改，CDC 对额外空间的要求可以忽略不计。

问题：时态表与上述两个相比如何？在速度、性能、存储空间使用方面。何时应该使用时态表而不是触发器或 CDC？我什么时候不应该？

我理解任何可能复杂的事情，因为 DB 审计背后的业务需求和技术限制不会有一个简单的答案，因为它在很大程度上取决于项目的要求和范围。但是，如果能对上述问题有更多的了解，我们将不胜感激。谢谢！

2021年编辑：由于对此一直有一些兴趣，几年后我已经非常熟悉上述所有内容，这里是性能方面的简短摘要：我对 SQL Server 2016 的某个版本进行了测试，涉及插入、更新和删除10000 行来自 40 个不同类型的表一一列出，并绘制了每个表的总体时间、基本锁定信息等。简单的总结是，触发器平均为操作增加了 500-1000% 的延迟，而使用临时表和 CDC 时，每个操作的额外延迟接近 10%。如果我有确切的结果会有所帮助，但我不再记得它们了。触发过程非常简化，但每个更改的列插入一行，而 temporal / cdc 插入一行，而不管其中更改了多少列。在这个意义上，由于同时插入多行的键争用，一些更改可能使触发器看起来比它们更慢。然而，很明显触发器是最不适合简单审计的工具。所以这是我在创建这篇文章时试图理解的差异的简单技术概要：

触发器只有在你真的需要一些内置到数据库中的自定义逻辑时才有用，以监视 DML 更改，修改特定数据，在特定实例中捕获用户 ID 等。但尽量避免它们像瘟疫一样。他们的表现很糟糕。如果您需要审计或日志记录，它们是您应该查看的最后一个地方。

临时表一旦运行起来就非常容易管理，尤其是在像 Always On 这样的 HADR 中。由于它们支持压缩并反映从父表到历史表的大多数模式更改，因此它们需要很少的维护。特别是对于新的 SQL Server 版本，您可以设置保留期以删除超过 x 年的数据，因此存储和清理方面的考虑也可以忽略不计。它们就像事情来临时一样容易被遗忘，除非对需要更改数据的父表进行一些奇特的更新，在这种情况下，您必须取消链接，修改父表和历史记录表，然后再次链接它们。但这些都是罕见的，而且相对容易做到。时态表包很健壮，可以很好地处理错误，因此您会发现它很难被意外破坏。

然后，CDC 非常适用于报告服务或类似的场景，在这些场景中，您不介意异步数据，但您需要分析更改，例如每晚批处理。您可以将保留设置设置为仅保留 x 天的数据，以将存储成本降至最低。也就是说，根据我的经验，CDC 很挑剔而且不是很稳定。DML 有时会在没有警告的情况下“破坏”它，因此您可能需要数据库级 DDL 触发器来警告您 CDC 跟踪的对象发生了变化。您可能还需要为 HADR 设置自定义监视作业，因为它本身不处理故障转移事件。并且 CDC 有一个非常讨厌的倾向，即在被禁用后无法重新启动，这与使用 MS 自己的作业未正确更新它的状态有关。这意味着它偶尔需要手动工作以确保正确删除清理和捕获作业及其引用。也就是说，SSIS / RS 集成得非常好，使他们可以轻松使用 CDC。

Answer 1

这取决于您的业务案例，临时表和变更数据捕获提供不同的功能。

时态表用于提供某个时间点的表版本。用例可能是一个缓慢变化的维度，您希望在其中跟踪维度属性的变化并随时报告它们。

可以在 OLTP 表上使用更改数据捕获，以允许您轻松地导出到数据集市。它将所有更改记录到单独的表中，因此您可以轻松查看自上次导出 LSN 点以来更改的行。