阿里云上的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的四种事务隔离级别
