阿里云上的rds 的隔离级别read committed​ 而不是repeatable-read设置原因

• 阿里云上的rds 的隔离级别 是read committed ，而不是原生mysql的“可重复读（repeatable-read）”，他们是基于什么原因这样设置的？

show variables like 'transaction_isolation';

--结果如下
Variable_name        Value
transaction_isolation    READ-COMMITTED

 

我们都知道： 

    提交读(不可重复读)和可重复读的区别在于:

    - 提交读 :    在本事务未提交之前其他事务的增删改操作提交后会影响读的结果。 读的是最新结果 。

    - 可重复读 : 在读的过程中数据始终是事务启动时的数据状态，未提交之前其他事物的增删改操作提交后都不会影响读的结果。 读的是快照结果

 

也就是说，read committed 隔离级别下， 同一个事务中，多次读取数据，可能是不一样的，  因为数据有可能已经被别的事务修改了。难到阿里云的rds不怕读的事务中，数据被修改吗？

 

为此，我咨询以前的ali内部同事，得到的回复是，需要研发在代码中控制好。这样是为了提高并发性。

 

• read committed 到底是怎样提供并发性的呢？

1、事务隔离级别为 读提交 时，写数据 只会锁住相应的行

2、事务隔离级别为 可重复读（更容易死锁） 时，如果 检索条件有索引 （包括主键索引）的时候，默认 加锁方式是next-key 锁 ；如果 检索条件没有索引 ，更新数据时 会锁住整张表 。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。

3、事务隔离级别为 串行化 时，读写数据都会 锁住整张表

4、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大

 

• 接下来是代码中要怎样控制的问题了？

 

对于上面出现的问题，可以使用乐观锁和悲观锁来避免。 

 

– 悲观锁 ：悲观锁假定当多个事务同时访问一个资源时，会出现以上问题。因而为了避免这些问题，每个事务在操作一个资源时，都先把资源锁起来，这样就完全排除了当前事务受其他事务的影响，但是使用悲观锁影响并发性能，所以应该谨慎。 

 

– 乐观锁 ：乐观锁假定多个并发事务访问一个资源时，靠数据库管理系统自身的锁机制就可以有效地避免这些问题。因而它主要依靠数据库的隔离级别来自动管理锁的工作。一旦出现以上问题，乐观锁会使用版本控制的手段来发现这些问题，并抛出异常，从而有效地避免不良后果的发生。

 

参考：

MySQL数据库事务各隔离级别加锁情况--read committed && MVCC

 

MySQL的四种事务隔离级别

https://www.cnblogs.com/huanongying/p/7021555.html