记一次事务隔离级别引起的问题

对于事务问题，其实也是很棘手的，特别是生产环境和测试环境不一样时最为头疼了。比如我最近遇到一个事务隔离级别的问题。先列一下事务的隔离级别吧。

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
读已提交（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

而mysql默认的事务隔离级别为repeatable-read。具体事务细节参考MySQL的四种事务隔离级别，我的问题也是在此文章的基础之上验证的。

我的问题场景是A项目调用B项目，两项目的通信使用的时HTTP，并且各自都开启了事务（数据库时公共的）。当B项目执行完并提交事务，A项目得到响应后去查询B项目的结果，但是查询不到。同事还做了不开启事务的测试，结果是可以查询到的，因此可以得知中间存在事务问题，并且查看了测试环境的事务隔离级别，数据库使用的是——repeatable-read，并且我们仔细检查了代码也没有特别针对事务进行设置，然而生产环境却没有这个问题。那么问题就来了，测试环境的事务隔离级别会是什么情况？为了查清这个问题，我们按照上面”MySQL的四种事务隔离级别“方式去尝试了一下，结果印证了这个问题。简单来说，在默认事务隔离级别情况下两个事务是独立的，不管B事务怎么修改A事务都是不会看到的。那么问题来了，为什么生产环境是可以的呢？于是就查询了一下生产环境的隔离级别——read-committed！！！也就是生产环境只要B事务提交了，A事务是可以看到的。其实使用read-committed是存在事务问题的，但是生产环境已经是这样了，测试环境只能去适应了。

另外，如果需要调整事务隔离级别可以使用这些命令。

1. 查看当前会话隔离级别

select @@tx_isolation; 

2. 查看系统当前隔离级别

select @@global.tx_isolation;

3. 设置当前会话隔离级别

set tx_isolation='read-committed';

4. 设置系统当前隔离级别

set global transaction isolation level read committed;