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

前言

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

问题

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

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

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

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

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

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

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

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

MySQL 中事务的隔离级别

一共分为四种，分别如下

隔离级别	释义	简介
READ-UNCOMMITTED	读取未提交	最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED	读取已提交	允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ	可重复读	对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE	可串行化	最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

隔离级别	脏读	不可重复读	幻读
READ-UNCOMMITTED	✔	✔	✔
READ-COMMITTED	×	✔	✔
REPEATABLE-READ	×	×	✔
SERIALIZABLE	×	×	×