进程成为死锁牺牲品的原因

Question

我有一个带有 Select 的过程，需要很长时间才能完成，大约需要 5 到 10 分钟。
我目前不使用 NOLOCK 作为 MS SQL 数据库引擎的提示。
同时，我们有另一个进程在执行更新和插入到同一个数据库和同一个表中.
第一个进程已经开始，最近以一条消息提前结束

SQLEXCEPTION：事务在锁资源上与另一个进程死锁，并被选为死锁牺牲品。

第一个进程在其他站点以相同的条件运行，但数据库较小，因此所讨论的 select 语句所需的时间要短得多（大约 30 秒左右）。在这些其他站点中，我没有在这些其他站点中收到死锁消息。我也没有在最初出现问题的站点上收到此消息，但是，我认为，随着数据库的增长，我相信我一定已经越过了某个门槛。以下是我的问题：

1. 事务执行所需的时间是否会使相关进程更有可能被标记为死锁牺牲品。
2. 如果我使用 NOLOCK 提示执行选择，这会解决问题吗？
3. 我怀疑作为 select 语句中 WHERE 子句的一部分检查的日期时间字段会导致查找时间变慢。我可以根据该字段创建索引吗？可取吗？

Answer 1

Q1：事务执行所需的时间是否会使相关进程更有可能被标记为死锁牺牲品。

没有。 SELECT 是受害者，因为它只读取数据，因此事务有 a lower cost 与之关联，因此被选为受害者：

默认情况下，数据库引擎选择作为死锁牺牲品的 运行回滚成本最低的事务的会话。 或者，用户可以指定会话的优先级 使用SET DEADLOCK_PRIORITY 语句的死锁情况。 DEADLOCK_PRIORITY 可以设置为 LOW、NORMAL 或 HIGH，或者 可以设置为范围（-10 到 10）内的任何整数值。

第二季度。如果我使用 NOLOCK 提示执行选择，这会解决问题吗？

没有。有几个原因：

• 您应该首先尝试通过调查根本原因来正确消除死锁
• 脏读是inconsistent reads。
• 指定脏读的正确方法是使用transaction isolation levels
• 有一个更好的解决方案：read committed snapshot。

第三季度。我怀疑在 select 语句中作为 WHERE 子句的一部分检查的日期时间字段会导致查找时间变慢。我可以根据该字段创建索引吗？可取吗？

大概吧。死锁的原因几乎很可能是索引不佳的数据库。在如此狭窄的条件下，10 分钟的查询是可以接受的，我 100% 确定您的情况是不可以接受的。

我有 99% 的信心声明您的死锁是由与更新冲突的大表扫描造成的。从捕获deadlock graph 开始分析原因。您很可能必须优化数据库的架构。在进行任何修改之前，请阅读此主题Designing Indexes 和子文章。

Answer 2

以下是这个特定死锁问题的实际发生方式和实际解决方式。这是一个相当活跃的数据库，每天发生 130K 事务。此数据库中表中的索引最初是聚集的。客户要求我们将索引设为非聚集索引。一旦我们这样做，僵局就开始了。当我们将索引重新建立为集群时，死锁停止了。

Answer 3

这里的答案值得一试，但您还应该检查您的代码。具体在这里阅读Polyfun的答案： How to get rid of deadlock in a SQL Server 2005 and C# application?

它解释了并发问题，以及在您的查询中使用“with (updlock)”如何纠正您的死锁情况 - 这实际上取决于您的代码正在做什么。如果您的代码确实遵循这种模式，那么在使用脏读等之前，这可能是一个更好的修复方法。

Answer 4

虽然@Remus Rusanu's 已经是一个很好的答案，如果有人期待更好地了解SQL Server 的死锁 原因和跟踪策略，我建议你阅读 Brad McGehee 的How to Track Down Deadlocks Using SQL Server 2005 Profiler