问题标签 [database-deadlocks]

添加触发器后，我遇到了死锁。有一个UserBalanceHistory表，每个事务有一行和一Amount列。添加了一个触发器来对列求和Amount并将结果放在相关的User表Balance列中。

我也开启了READ_COMMITTED_SNAPSHOT：

我有一个正在运行的并行进程正在创建UserBalanceHistory条目，显然如果它同时工作User，就会发生死锁。建议？

我记录了 ASP.NET 应用程序引发的异常。

消息：事务（进程 ID 56）在锁上死锁 | 与另一个进程通信缓冲区资源，并已被选为死锁牺牲品。重新运行事务。

我确定其原因是，我selects在 SSMS 中直接在应用程序中同时查询的表上运行了一些。

所以现在我的问题是：

• 我可以更改 SQL-Server 选择“死锁受害者”的优先级吗？我想选择“我自己”（SSMS）作为死锁受害者而不是 ASP.NET，因为它是一个时间紧迫的应用程序，并且我重新运行手动查询比让用户接受错误更容易。

先感谢您。

我试图准确地了解这里发生了什么。我意识到选择/更新组合可能会导致死锁 - 在这种情况下需要 longggg 等待。

场景是这个 Query A 是一个使用三个索引的 select 语句（非常简化）

索引都是非聚集的：

1. Plan_Id
2. 日期_输入
3. Plan_Id, nabp

都有 ProblemTable.Unique_Id 的“输出”

查询 B 是使用两个索引的更新语句

索引是：

1. 非集群 Date_Entered ASC、源 ASC、DataStartOffset ASC
2. 索引 1 的索引搜索结果中使用的 Unique_Id 上的聚集索引。

更新查询：

我知道.. dateadd 很傻。这不是我写的：）

因此，这会扫描与查询 A不同的索引，但也使用 Date_Entered。由于这种情况，长时间的等待不断发生。死锁似乎不会发生，但它可能会导致等待时间超过 5 分钟，其中每个查询通常以秒为单位执行。

请注意，这也发生在 INSERT into ProblemTable

所以 - 我猜 SELECT stmt 会在它最终根据 NC 索引搜索确定选择的行上获取锁，然后 update 语句会尝试在从 NC 索引上搜索返回的行上获取锁。但是为什么它只是花费了 longgggg 时间而没有发生死锁呢？

那么问题基本上是：

1 为什么等待时间长而不是死锁？2. 这是什么原因造成的？

这里有足够的信息吗？

编辑 1这两个查询都相当快，而且都不会花这么长的时间。长时间是这里“某些”未知锁定问题的结果。没有其他显式交易正在进行。

当我们得到：

（com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException：尝试获取锁定时发现死锁；尝试重新启动事务）或（事务超时）？

我正在使用 MySQL（innoDB ENGINE）和 Java。请帮助并链接任何有用的资源或代码。

我有两个有时同时运行的进程。

第一个是批量插入

第二个是从存储过程批量更新

--存储过程的部分代码--

第一个进程运行一段时间（取决于传入的记录负载），第二个进程总是死锁牺牲品。

我是否应该设置SqlBulkCopyOptions.TableLock让第二个进程等到资源被释放。

我正在使用 mysql 5.0.92。最近，我们有很多插入到一张表的死锁，其中行的插入（以及更新或删除）相对较快。我在 StackOverflow、mysql 文档和论坛中研究了这里的问题，但没有理解这个问题。令我困惑的一件事是，其中一张表没有根据 innodb 状态锁定任何资源。

这是输出SHOW INNODB STATUS：

该表定义如下：

帮助将不胜感激。

我有下表

以及以下死锁问题：

你能帮我理解这个死锁的机制吗？

这两个查询是从不同的线程发出的。每个线程在查询中都有自己的 node_id。没有两个查询具有相同的 node_id。

我怀疑，我可以通过在字段（node_id，status）上创建复合索引来解决这种情况，但我认为这不是一个好的解决方案。我需要了解问题的本质。

同一查询上的这些死锁会定期发生，而不是一次或两次。

EXPLAIN 对受影响的查询给出了有趣的结果：

MySQL 版本是 5.5。

此外，在死锁的时刻，表不包含与受影响查询的条件匹配的行（例如 select usr_sl3. task. idfrom usr_sl3. taskwhere ( usr_sl3. task. node_id= 95 and usr_sl3. task. status= 'EXECUTING') for update 根本不会产生任何行）。

提前致谢。

有人可以帮我阅读/理解这个死锁图吗？

我不明白为什么进程 75 请求锁定他已经锁定的对象？

我一直在我的实时应用程序中遇到死锁错误，并已将它们（使用 sql server profiler 的“死锁图”）跟踪到after insert我的表上定义的触发器。

基本上情况是这样的——我想跟踪插入到某些表中的记录，按时间范围分组。（即在 12:00-12:10 之间，有 7 条记录被插入Users）。
我实现它的方式是after insert在这些表上创建触发器，因此当插入记录时，我会更新统计表中的相应记录。（见下文）。

正如我所说，这似乎造成了僵局。发生的事情是（我认为，我还没有找到确定的方法）是每个事务在提交之前可能会在多个表中插入/更新多个记录。
所以事务 1 出现，更新统计表中的某条记录（从而锁定它），然后继续更新表 B 中的记录。
同时，事务 2 将一条记录插入到表 B 中（从而锁定它），并尝试更新统计表中的记录 - 导致死锁。

（这当然是可能发生的事情的一个非常简化的版本。实际上我还不是 100% 确定）。

现在我最初的想法是看看是否有可能在 commit 之后执行触发器，以便事务不再持有任何锁。
但是，据我所知，没有这样的选择。

另一种解决方案是完全消除触发器，并改用某种批处理作业。

欢迎任何其他关于首选解决方案的想法/想法。

触发代码：

我找不到任何讨论有多个可能的索引可用于备份 FK 约束的情况。

从下面的测试看来，在 FK 创建时，FK 被绑定到特定索引，这将始终用于验证 FK 约束，无论以后是否添加新的更好的索引。

任何人都可以指出任何确认或否认这一点的资源吗？