高并发 upsert 导致死锁和查询时间 > 30s

Question

我正在开发一个应用程序，该应用程序使用 EF6 进行大多数数据库操作，并且在大多数情况下，数据库内容是非关键的，并且不会承受很大的负载。此规则有一个例外，我们有可能 100/s 的事件流传入，需要根据列值在特定表中插入或更新行。

总的来说，我对 SQL 有点弱，但我编写了这个查询来插入或更新并返回元素的 id：

DECLARE @Id [int];

MERGE {tableName} WITH (UPDLOCK) AS target
USING (SELECT @MatchName AS id) AS source
ON source.id = target.MatchColumn
WHEN MATCHED
    THEN UPDATE SET @Id = target.Id, ...
WHEN NOT MATCHED
    THEN INSERT (...) VALUES (...);

IF @Id IS NULL
BEGIN
    SELECT @Id = CAST(SCOPE_IDENTITY() as [int]);
END;
SELECT @Id;

它在 (EF) 可序列化事务块内完成，它是唯一在显式事务中执行的东西，也是更新此表的唯一代码。 （其他东西可以读）。如果事务被数据库回滚（EF 抛出异常），它会立即重试最多 3 次。

问题在于，当我们开始进入更高负载的情况时，我们最终可能会处于这样一种状态，即有很多东西都在尝试更新数据库，并且针对该表的查询可能开始需要 30 多秒（对其他表的查询仍然存在）美好的）。我的印象是，即使这在可序列化事务中执行，它也只会锁定由合并匹配表达式选择的行，这应该是一个相对快速的操作。

过去几天我一直在做一些研究，有些人建议在默认事务中只有HOLDLOCK 就足够了，而其他人则声称需要可序列化的事务，否则您可能会遇到数据完整性问题。

我希望有人能解释为什么会发生长时间的死锁，并详细说明在这种情况下哪种锁定机制是最佳的。

Answer 1

默认情况下，merge 获取 updlocks，因此 with (updlock) 不会为您做任何事情。将您的updlock 更改为holdlock（或serializable）并在事务中运行该语句将保证在操作期间获取并持有正确的锁。

为防止并发会话使用相同的密钥插入数据，必须获取不兼容的锁以确保只有一个会话可以读取密钥，并且必须保持该锁直到事务完成。

• UPSERT Race Condition With Merge - Dan Guzman

---

你需要使用set transaction isolation level serializable吗？

在这种情况下，如果上面的代码就是事务中的全部内容，我认为将事务隔离级别显式设置为serializable 不会有任何区别。 merge with (holdlock) 将默认获取与共享锁不兼容的更新锁，使用holdlock 提示解决了Dan Guzman 在上面引用的文章和摘录中解释的竞争条件问题。

---

with (holdlock) 是table hint。表提示会覆盖语句的默认行为。

如果您的事务中有其他语句，那么这些语句将受到事务隔离级别与默认隔离级别的差异或显式设置的set transaction isolation level（会话级别）的影响，除非被表提示覆盖。

最高粒度获胜：

• 最低：数据库（默认为read committed）
• 中间：会话 (set transaction isolation level ...)
• 最高：表格提示 (with (updlock, serializable))

有关事务隔离级别的更多信息：

• SQL Server Isolation Levels: A Series - Paul White
• Questions About T-SQL Transaction Isolation Levels You Were Too Shy to Ask - Robert Sheldon