[MySQL]为什么大厂选择读已提交

为什么读已提交的并发性更好

在数据库中，锁的时间和范围是影响并发性的重要因素。已提交读（Read Committed）隔离级别与可重复读（Repeatable Read）的主要区别就在于它们在读取数据时对锁的使用方式不同。让我们详细看看为什么已提交读的锁的时间和范围更小。

1. 已提交读（Read Committed）如何管理锁#

在已提交读隔离级别下：

• 写操作：当事务执行插入、更新或删除操作时，数据库会对被修改的数据行加上排他锁（Exclusive Lock），这可以防止其他事务在该行数据未提交时读取或修改它。
• 读操作：当事务执行读取操作时，数据库只读取那些已经被提交的行数据，读取时不会对已提交的数据加锁，即读取操作不会阻塞其他事务的写操作。

因此，已提交读的特性决定了它的锁的时间和范围非常有限：

• 写锁：仅在事务执行写操作期间持有，并且在该事务提交后立即释放。也就是说，写锁只存在于事务的修改过程中，时间较短。
• 读操作不加锁：已提交读在读取数据时，不会对数据加任何锁。它只是确保读取到的是已经提交的数据，因此读操作不会阻塞其他事务的写操作。

这就意味着，事务只在短时间内需要持有锁，尤其是读取操作几乎不加锁，并发性因此较高。

2. 可重复读（Repeatable Read）的锁管理#

在可重复读隔离级别下：

• 写操作：同样会对数据行加排他锁，和已提交读类似。
• 读操作：当事务读取一行数据时，数据库会对该数据行加上共享锁（Shared Lock），以确保在当前事务结束之前，其他事务无法修改这行数据。共享锁的作用是防止其他事务进行写操作，从而保证当前事务内的数据是一致的。

由于可重复读要求保证同一事务中的多次读取结果一致，这意味着在事务的整个生命周期内，数据行上的共享锁必须保持直到事务提交或回滚。即便当前事务只是读取操作，也会阻止其他事务对相同数据行进行写操作。这会导致：

• 锁的范围更大，读锁不仅锁住了正在读取的行，还影响其他事务的修改操作。
• 锁的时间更长，锁定直到事务完成，而不仅仅是读取时刻。

这种设计牺牲了并发性，因为多个事务在并发读写相同数据时，可能需要等待当前事务释放锁。

3. 锁的范围和时间差异具体体现#

在已提交读下：#

• 写锁：仅在修改数据时加锁，写操作结束后立刻释放。
• 读锁：不存在读锁，因为已提交读只读取已提交的数据，所以不需要阻止其他事务进行修改。

在可重复读下：#

• 写锁：与已提交读类似。
• 读锁：为了保证可重复读，读操作会对数据行加共享锁，锁定范围包括当前事务读取的所有数据行，锁定时间直到事务结束。

4. 并发性的提升：已提交读的锁更“轻量”#

因为已提交读不需要在读操作中加锁，它允许更多的并发读写操作：

• 读不阻塞写：一个事务在读取数据时，其他事务可以同时对相同的数据进行写操作，只要这些写操作在提交时不会与当前事务发生冲突（例如读写同一行）。
• 写不阻塞读：在写操作期间，其他事务仍然可以读取那些已经提交的数据。这种模型大大减少了事务之间的相互阻塞，提升了系统的并发能力。

总结：#

已提交读的锁的时间和范围更小，主要是因为它不对读取操作加锁，并且对写操作的锁只在修改时存在，修改完成后立即释放。而可重复读为了保证数据一致性，对读取操作加了共享锁，并且在事务结束前不会释放，这导致了锁的时间更长，范围更大，影响并发性。

已提交读在高并发的场景下能够更好地发挥性能优势，适合对一致性要求较低的应用。

为什么MySQL选择REPEATABLE READ作为默认隔离级别？

主要是因为MySQL在主从复制的过程是通过bin log 进行数据同步的，而MySQL早期只有statement这种bin log格式，这种格式下，bin log记录的是SQL语句的原文。

当出现事务乱序的时候，就会导致备库在 SQL 回放之后，结果和主库内容不一致。

为了解决这个问题，MySQL采用了Repetable Read这种隔离级别，因为在 RR 中，会在更新数据的时候增加记录锁的同时增加间隙锁。可以避免这种情况的发生。

大家可以通过这个命令查看数据库当前的隔离级别：

select @@tx_isolation;

那么，这里不禁就有疑问了，为啥阿里要把这个数据库隔离级别修改成 RC 呢，背后有什么思考吗？

RR 和 RC 的区别#

想要搞清楚这个问题，我们需要先弄清楚 RR 和 RC 的区别，分析下各自的优缺点。

一致性读#

一致性读，又称为快照读。快照即当前行数据之前的历史版本。快照读就是使用快照信息显示基于某个时间点的查询结果，而不考虑与此同时运行的其他事务所执行的更改。

在MySQL 中，只有READ COMMITTED 和 REPEATABLE READ这两种事务隔离级别才会使用一致性读。

• 在 RC 中，每次读取都会重新生成一个快照，总是读取行的最新版本。
• 在 RR 中，快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照。

在数据库的 RC 这种隔离级别中，还支持"半一致读" ，一条update语句，如果 where 条件匹配到的记录已经加锁，那么InnoDB会返回记录最近提交的版本，由MySQL上层判断此是否需要真的加锁。

锁机制#

数据库的锁，在不同的事务隔离级别下，是采用了不同的机制的。在 MySQL 中，有三种类型的锁，分别是Record Lock、Gap Lock和 Next-Key Lock。

• Record Lock表示记录锁，锁的是索引记录。
• Gap Lock是间隙锁，锁的是索引记录之间的间隙。
• Next-Key Lock是Record Lock和Gap Lock的组合，同时锁索引记录和间隙。他的范围是左开右闭的。

在 RC 中，只会对索引增加Record Lock，不会添加Gap Lock和Next-Key Lock。

在 RR 中，为了解决幻读的问题，在支持Record Lock的同时，还支持Gap Lock和Next-Key Lock；

主从同步#

在数据主从同步时，不同格式的 binlog 也对事务隔离级别有要求。

MySQL的binlog主要支持三种格式，分别是statement、row以及mixed，但是，RC 隔离级别只支持row格式的binlog。如果指定了mixed作为 binlog 格式，那么如果使用RC，服务器会自动使用基于row 格式的日志记录。

而 RR 的隔离级别同时支持statement、row以及mixed三种。

为什么互联网公司选择使用 RC#

提升并发#

互联网公司和传统企业最大的区别是什么？

高并发！

没错，互联网业务的并发度比传统企业要高处很多。2020年双十一当天，订单创建峰值达到 58.3 万笔/秒。

很多人问，要怎么做才能扛得住这么大的并发量。其实，这背后的优化多到几个小时都讲不完，因为要做的、可以做的事情实在是太多了。

而有一个和我们今天这篇文章有关的优化，那就是通过修改数据库的隔离级别来提升并发度。

为什么 RC 比 RR 的并发度要好呢？

首先，RC 在加锁的过程中，是不需要添加Gap Lock和 Next-Key Lock 的，只对要修改的记录添加行级锁就行了。

这就使得并发度要比 RR 高很多。

另外，因为 RC 还支持"半一致读"，可以大大的减少了更新语句时行锁的冲突；对于不满足更新条件的记录，可以提前释放锁，提升并发度。

减少死锁#

因为RR这种事务隔离级别会增加Gap Lock和 Next-Key Lock，这就使得锁的粒度变大，那么就会使得死锁的概率增大。

死锁：一个事务锁住了表A，然后又访问表B；另一个事务锁住了表B，然后企图访问表A；这时就会互相等待对方释放锁，就导致了死锁。

总结
本文介绍了一些 MySQL数据库的 RR 和 RC 两种事务隔离级别。他们主要在加锁机制、主从同步以及一致性读方面存在一些差异。

而很多大厂，为了提升并发度和降低死锁发生的概率，会把数据库的隔离级别从默认的 RR 调整成 RC。

当然，这样做也不是完全没有问题，首先使用 RC 之后，就需要自己解决幻读的问题，这个其实还好，很多时候幻读问题其实是可以忽略的，或者可以用其他手段解决。

还有就是使用 RC 的时候，不能使用statement格式的 binlog，这种影响其实可以忽略不计了，因为MySQL是在5.1.5版本开始支持row的、在5.1.8版本中开始支持mixed，后面这两种可以代替 statement格式。