SQL 服务器 2012 : DATETIME discrepancies between inserts and triggers

Question

我们遇到了一个非常奇怪的问题，即在调用 GETUTCDATE() 时，第二条语句中的返回值比第一条语句中的返回值稍微早一些。我们的场景如下:

1. 我们插入到一个表中以跟踪用户的当前状态，该表有一个触发器，在该触发器上使用 DATETIME 字段插入到关联的用户过去状态的历史表中，并且插入调用 GETUTCDATE()

2. 完成此操作后，我们将获得另一个表，其中包含我们插入到调用 GETUTCDATE() 中的关联记录，该记录跟踪哪个部分更新了用户状态。

所以流程是:

1. 插入UserStatuses
2. 触发 UserStatuses 表插入 UserStatusesHistory 调用 GETUTCDATE()
3. 然后我们插入 OwningStatuses 表调用 GETUTCDATE()

我们发现在某些情况下，UserStatusesHistory 上的DATETIME 晚于 OwningStatuses 上的DATETIME表。

当 OwningStatuses 上的 GETUTCDATE() 在 UserStatusesHistory< 的 GETUTCDATE() 之后被调用时，这怎么可能呢？/表？

在某些场景中触发器是异步运行的吗？ (我不敢相信这是因为它违背了我所阅读的所有内容，而且我们没有使用任何服务代理)。

在某些情况下，GETUTCDATE() 是否可能在过程开始时被缓存，而这个缓存值没有被带入触发器？

Answer 1

由于 SQL 的声明性特性，数据库引擎可能会以它认为合适的任何顺序(只要不影响语义)自由评估 SQL 语句的各个部分。您关于 GETUTCDATE() 可能被缓存的建议是合理的。

我知道这不能回答您的问题。但是无论 SQL2012 中 GETUTCDATE 的实现如何，它都可能在未来的版本中发生变化。所以避免依赖它，否则 future 的升级可能会成为一个真正的痛苦。以不依赖任何关于评估顺序的假设的方式实现您的逻辑。

在您的具体情况下，我看到了一些可能的解决方案。

1. 如果您对 OwningStatuses 的时间比 UserStatusesHistory 稍微晚没有问题，那么如果您发送第三步，它可能已经有所帮助作为单独的批处理发送到 SQL Server。
2. 交换步骤 2 和 3；并让触发器查询 OwningStatuses 而不是自己编造日期。
3. 停止使用触发器；考虑这一点的理由不止一个。