Looking at the logs it does have that issue, but your description I think is wrong because he is operating in a local transaction using the same connection, and you didn't describe clearly the point in time of the query and insert for transaction 1 and the query and insert for transaction 2, and according to your description transaction 1 has got the gap lock and the intent lock, so why is it waiting for transaction 2?
7条答案
按热度按时间x7rlezfr1#
Why is there a deadlock, do you have more log information?
cl25kdpy2#
在并发的情况下，事务1 、事务2 在 代码上图代码A点执行 select ... from tcc_fence_log for update语句时， 如果查询事务记录不存在会添加间隙锁，如果两个事务添加的间隙锁范围包含两个事务之后insert事务记录的记录范围（上图代码B） 事务1会添加插入意向锁进入等待，等待事务2提交事务释放间隙锁 事务2会添加插入意向锁进入等待，等待事务1提交事务释放间隙锁 这就会形成数据库死锁； 日志信息：
vngu2lb83#
MySQL 8默认事务隔离级别 可重复读
xqkwcwgp4#
Looking at the logs it does have that issue, but your description I think is wrong because he is operating in a local transaction using the same connection, and you didn't describe clearly the point in time of the query and insert for transaction 1 and the query and insert for transaction 2, and according to your description transaction 1 has got the gap lock and the intent lock, so why is it waiting for transaction 2?
看日志确实有该问题，但是你的描述我认为是错误的，因为他在一个本地事务中，使用的是相同的connection进行的操作，你也没有描述清楚事务1的查询和插入，以及事务2的查询和插入的时间点，按照你的描述，事务1已经拿到间隙锁和意向锁，为什么要等待事务2？
f4t66c6m5#
You can change to rc isolation level, which should solve the problem directly
ha5z0ras6#
我觉得我还是需要把它描叙清楚:(我个人觉得在MySQL默认隔离级别下出现的概率还是比较高的)
izj3ouym7#
我觉得我还是需要把它描叙清楚:(我个人觉得在MySQL默认隔离级别下出现的概率还是比较高的)
Check the MySQL version.In higher versions of the database, there is no GAP lock for equivalence operations.