莫名锁表？ --- mysql的事务隔离级别

前言

系统响应超时
系统访问数据库特别慢
莫名提示锁等待超时
数据库锁表
事务长时间等锁，直到超时
以上问题都可能是事务锁表导致的

问题

今天测试反馈系统批量处理莫名提示锁等待超时，再次操作查看数据库事务确实存在等锁情况，甚至死锁。刚开始是偶尔出现，后来一直就是死锁，导致其他操作也操作不了。
刚开始发现数据库中操作插入的时候会进入锁等待

怀疑是这张表中主键自增导致的锁表，于是将表改为指定主键，问题依然存在。

后来想起来之前有个需求，给信息设置每日连续自增编号，当时为了严谨用了分布式锁Redisson和事务控制@Transactional，会不会是这个导致的锁表？于是把这个编号生成的代码注释掉，果然表事务不会再进入锁等待。

所以到底是什么导致的锁表呢？顺着思路往下，会不会是事务控制导致到锁表？问问chatGPT.

wo: 一个事务在更新表A，另一个事务要insert数据到表A的时候必须要等前一个事务提交吗？

ChatGPT:
在 MySQL 中，默认情况下，当一个事务更新了表 A 中的某些数据时，另一个事务想要向表 A 插入数据时，必须等待第一个事务提交或者回滚后才能执行插入操作。这是因为默认的事务隔离级别为 REPEATABLE READ，这个隔离级别下，其他事务不能对已经被读取的数据进行修改。
换句话说，如果一个事务正在更新表 A 的数据，而另一个事务想要向表 A 插入数据，后者必须等待前者提交或者回滚后才能执行插入操作，这样可以避免并发更新时的数据不一致问题。
需要注意的是，在不同的事务隔离级别下，事务之间的行为是不同的。例如，在 READ COMMITTED 隔离级别下，另一个事务可以向表 A 插入数据，即使有另一个事务正在更新表 A 的数据，只要更新操作提交后，插入操作就可以执行。因此，事务隔离级别的设置对于并发访问数据库的行为有重要影响，需要根据应用场景进行合适的选择。
1
2
3
4
5
6

这里提到了一个关键点–事务隔离级.mysql是有多种事务隔离级别供选择的，而默认的 READ COMMITTED 隔离级别，就可能会导致上述的问题。

要想复现我上述的问题其实很简单，在本地启动两个服务（服务1，服务2），分别都对表A进行写入操作，并且开启事务，在服务1的事务中打上断点（或者sleep）,这时候访问服务1，程序进入sleep，再访问服务2，观察服务2的程序会进入等待，查看数据库事务 select * from information_schema.innodb_trx; 会发现有一个事务正在等待锁，就是服务2的事务。
– 上复现方式可能描述不太准确

MySQL 中事务的隔离级别

一共分为四种，分别如下