Raj*_*oel 5 mysql hibernate database-deadlocks hibernate-envers
在并行运行少量事务时，大多数情况下，我会陷入僵局：
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-09-04 06:19:12 0x2b01917c7700
*** (1) TRANSACTION:
TRANSACTION 14470484, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 1136, 7 row lock(s), undo log entries 4
MySQL thread id 69372, OS thread handle 47285779531520, query id 10366178979 172.31.19.11 master updating
update `VerificationActionLog_AUD` set `REVEND`=427956 where `id`=138136 and `REV`<> 427956 and `REVEND` is null
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7307 page no 1108 n bits 128 index PRIMARY of table `TestDB`.`VerificationActionLog_AUD` trx id 14470484 lock_mode X waiting
Record lock, heap no 60 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
...
*** (2) TRANSACTION:
TRANSACTION 14470485, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
11 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 4
MySQL thread id 69395, OS thread handle 47285735814912, query id 10366178981 172.31.19.11 master updating
update `VerificationActionLog_AUD` set `REVEND`=427957 where `id`=138137 and `REV`<> 427957 and `REVEND` is null
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 7307 page no 1108 n bits 128 index PRIMARY of table `TestDB`.`VerificationActionLog_AUD` trx id 14470485 lock_mode X locks rec but not gap
Record lock, heap no 60 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
...
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 7307 page no 1108 n bits 128 index PRIMARY of table `TestDB`.`VerificationActionLog_AUD` trx id 14470485 lock_mode X waiting
Record lock, heap no 60 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
...
*** WE ROLL BACK TRANSACTION (2)
我正在尝试推断这些陈述所解释的内容。根据我的理解，事务2锁定的主索引TestDB。VerificationActionLog_AUD。同时，事务2也正在等待相同的锁。单个事务如何可能持有并等待相同的锁？
我从这些陈述中推断出错误吗？我如何才能继续解决这些僵局。此外，死锁仅适用于AUD表，这些表通过envers在后台进行维护，如何解决此问题？
这是由于间隙锁而发生的。间隙锁是对索引记录之间间隙的锁定，或者对第一个索引记录之前或最后一个索引记录之后的间隙的锁定
\n\n假设您有相邻的id1 和 2。当从 2 个不同的会话同时执行过程时，每个会话都会在两个索引记录上放置一个间隙锁（值id1 和 2 - 也可能是 0 、4、5 ，但是让\'为了简单起见，假设只有 2 个），并且每个都必须等待另一个释放锁才能执行插入。
\n\n\nInnoDB 中的间隙锁是\xe2\x80\x9cpurely 抑制\xe2\x80\x9d，这意味着它们仅\n 阻止其他事务插入间隙。它们不会阻止不同的事务在同一间隙上获取间隙锁。因此，\n 间隙 X 锁与间隙 S 锁 * 具有相同的效果。”
\n
解决方案：
\n\n\n\n\n间隙锁定可以显式禁用。如果您将事务隔离级别更改为 READ COMMITTED 或启用 innodb_locks_unsafe_for_binlog 系统变量（现已弃用），则会发生这种情况。在这些情况下，间隙锁定对于搜索和索引扫描禁用，并且仅用于外键约束检查和重复键检查。
\n
参考文献：
\n\n| 归档时间： |
|
| 查看次数： |
108 次 |
| 最近记录： |