朋友面试的时候遇到灵魂发问“为什么阿里云把读已提交用作隔离级别？”,后续复盘讲给我的时候，我直接一个问号，mysql自己默认隔离级别都是可重复度，阿里云还能比官方更懂吗？
- 读已提交（Read committed简称rc）借助MVCC解决了脏读问题；在事务中可以读到其他事务提交了的最新更新。
- 可重复读（repeatable read 简称rr）RR在MVCC的基础上 在每次查询的时候不生成新的读视图，而是复用创建事务时候的读视图的快照，这样解决了可重复读的问题。而且，可重复读（repeatable read 简称rr）是MySQL默认的隔离级别
但是这个问题出现在面试上，说明确实是有这个情况存在，是想考核背后原因，不可能有诈啊。所以赶紧特意去查了一下蚂蚁的数据库隔离级别，和阿里拆分没几年，应该会沿用配置，果不其然，就是RC！
可以模拟一下阿里云的系分，在事务隔离级别选型分析一下。
| 选型文档： 背景： 对若干客户提供数据库服务，客户以互联网企业居多，阿里云需要提供高强度的并发能力，并发性能很重要。 |
隔离级别名称 | 优点 | 缺点 |
|---|---|---|---|
| 串行 | 精确的一致性和可重复的结果 | 并发度极低 | |
| RU | |||
| RC | |||
| RR |
大型数据库环境和企业级应用中，事务隔离级别的选择需要平衡数据的一致性、系统的并发性能以及可能遇到的问题（如脏读、不可重复读、幻读）之间的关系。，很多大厂和数据库系统默认采用这个级别。对于一般的业务，我们并发要求没有高到用读未提交这种脏读的隔离级别，却也无需使用串行来极端的保证，剩下的选择只有RC和RR了，我认为选RC的原因有可能有以下几点：（按照权重排序）
-
提高并发性 避免锁竞争：与更严格的隔离级别（如RR甚至于序列化）比较，"读已提交"能够提供更好的并发性能。这对于高并发环境下的大厂尤其重要，因为它们需要处理大量同时发生的事务而不至于过度锁定资源，导致系统性能下降。还可以避免锁竞争
a. 非锁定读取：RC隔离级别允许事务读取其他事务已经提交的数据，而不需要持有锁。这意味着在RC级别，读操作不会阻塞写操作，从而减少了锁竞争。 b. 锁的持有时间：在RC级别，事务只有在读取数据时才需要短暂的锁定，一旦读取完成，锁就会被释放。这减少了锁的持有时间，降低了死锁的风险。 c. 锁的粒度：RC通常使用行级锁或更低粒度的锁，而不是像RR那样可能需要表级锁。这减少了锁的范围，允许更多的并发操作。 d. 锁的兼容性：RC级别下的锁兼容性更好，允许更多的并发访问，因为读锁不会阻止写操作，写锁只在写事务实际执行写操作时才持有。
- 成本与实现的平衡："读已提交"隔离级别相比较于"可重复读"（Repeatable Read）和"序列化"（Serializable）来说，在实现上更为简单和高效，因为它不需要像处理可重复读和幻读那样复杂的锁机制或MVCC（多版本并发控制）实现。这意味着从成本效益角度，"读已提交"为数据库管理系统提供了一个合理的性能和数据一致性之间的折中方案。
而且，对于大多数业务 在一个事务中能读到另一个最新的事务提交的数据 难道是有问题的吗？我觉得反而让事情变得更简单了。
那么 为什么mysql会采用可重复度来做默认的隔离级别呢？
todo