Rowversion数据库锁性能

Question

正如文档所述，每次在整个数据库范围内使用全局自动递增数字更新行时，rowversion数据类型都会自动更新。

我的问题如下：假设我对具有rowversion列的表有 10000 个并发更新。由于所有人都尝试以原子方式访问和更新该全局号码，因此我想所有这些都以“串行”方式处理，与不需要访问该号码的表相比，这可能会降低性能。

它是否正确？。

Answer 1

我想所有这些都是以“串行”方式处理的，与不需要访问该数字的表相比，这可能会降低性能。

理论上是的。在实践中，您必须衡量效果才能知道它是否重要。

当前rowversion值缓存在内存中，并使用cmpxchg指令（在 中DBTABLE::GetNewDbTimestamp）进行原子更新。由于多个会话同时请求新的 rowversion 值而导致的任何冲突都由自旋锁（在sys.dm_os_spinlock_statsDBTABLE中键入）处理。监控 DMV 中的退避和睡眠可能是查看它是否会导致问题的第一步。

与实际插入或更新行所需的大量工作相比，维护时间戳值可能相当微不足道。真正确定的唯一方法是在合适的工作负载上测试它，同时插入或更新许多具有rowversion列的表。

作为快速测试，我运行了两个会话，将具有单个整数值的 500,000 行插入到具有rowversion列的表变量中。该批次在每个连接上重复 100 次，每次插入总数为 50,000,000 个。

SET NOCOUNT ON;
DECLARE @T AS table (i integer, rv rowversion);
INSERT @T (i) SELECT N.n FROM dbo.Numbers AS N WHERE N.n BETWEEN 1 AND 500000;
GO 100

典型结果是执行时间为 45 秒：

使用二进制（8）列默认值 0x，相同的测试运行 15 秒。

所以肯定存在与rowversion相关的成本。但我确实怀疑这通常会成为问题的主要原因。也许如果大量表具有行版本列并且全部同时以高速率插入/更新。

我想如果本机编译的内存优化表支持rowversion，我们可能会更接近这成为非持久表的真正瓶颈的时间，但也许甚至到那时都不会。身份和序列使用类似的机制，我还没有听到任何关于这成为一个具体问题的报告。

一些相关阅读：

• 为什么备份/恢复后@@dbts 会增加？
• 诊断和解决 SQL Server 上的自旋锁争用
• sys.dm_os_spinlock_stats.backoffs 不断增加，没有 sqlos.spinlock_backoff 事件