您的位置: 首页  >  文章  >  mysql事务的搬砖以及理解

mysql事务的搬砖以及理解

分类: 文章 • 2025-01-06 17:22:10

       最近看到了一个比较牛x的博客https://www.cnblogs.com/rjzheng，特此搬砖。以及在此篇之下的bloghttps://www.cnblogs.com/yubaolee/p/10398633.html

引言

开始我们的内容，相信大家一定遇到过下面的一个面试场景

面试官：“讲讲mysql有几个事务隔离级别？”
你：“读未提交，读已提交，可重复读，串行化四个！默认是可重复读”
面试官：“为什么mysql选可重复读作为默认的隔离级别？”
(你面露苦色，不知如何回答！)
面试官:"你们项目中选了哪个隔离级别？为什么？"
你：“当然是默认的可重复读，至于原因。。呃。。。”
(然后你就可以回去等通知了！)

Mysql默认的事务隔离级别是可重复读(Repeatable Read)，那互联网项目中Mysql也是用默认隔离级别，不做修改么？
OK，不是的，我们在项目中一般用读已提交(Read Commited)这个隔离级别！然后我看到这里的时候，我想说可重复读，读已提交是什么！！！果断去普及了一下知识

读未提交（Read Uncommitted）

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别，虽然拥有超高的并发处理能力及很低的系统开销，但很少用于实际应用。因为采用这种隔离级别只能防止第一类更新丢失问题，不能解决脏读，不可重复读及幻读问题。个人理解：A B 事务  A事务没有结束更改了数据，事务未结束 B事务可以看到A更改的数据。第一类更新丢失：在完全未隔离事务的情况下，两个事务更新同一条数据资源，某一事务完成，另一事务异常终止，回滚造成第一个完成的更新也同时丢失 。

读已提交（Read Committed）

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别可以防止脏读问题，但会出现不可重复读及幻读问题。

可重复读（Repeatable Read）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。这种隔离级别可以防止除幻读外的其他问题。

可串行化（Serializable）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读、第二类更新丢失问题。在这个级别，可以解决上面提到的所有并发问题，但可能导致大量的超时现象和锁竞争，通常数据库不会用这个隔离级别，我们需要其他的机制来解决这些问题:乐观锁和悲观锁。

这四种隔离级别会产生的问题如下（网上到处都有，懒得画了）：

mysql事务的搬砖以及理解

脏读（Dirty Read）

A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。

不可重复读（Nonrepeatable Read）

B事务读取了两次数据，在这两次的读取过程中A事务修改了数据，B事务的这两次读取出来的数据不一样。B事务这种读取的结果，即为不可重复读（Nonrepeatable Read）不可重复读有一种特殊情况，两个事务更新同一条数据资源，后完成的事务会造成先完成的事务更新丢失。这种情况就是大名鼎鼎的第二类丢失更新

幻读（Phantom Read）

B事务读取了两次数据，在这两次的读取过程中A事务添加了数据，B事务的这两次读取出来的集合不一样。不可重复读差不多，但幻读强调的集合的增减，而不是单独一条数据的修改

正文

我们先来思考一个问题，在Oracle，SqlServer中都是选择读已提交(Read Commited)作为默认的隔离级别，为什么Mysql不选择读已提交(Read Commited)作为默认隔离级别，而选择可重复读(Repeatable Read)作为默认的隔离级别呢？

Why?Why?Why?

这个是有历史原因的，当然要从我们的主从复制开始讲起了！
主从复制，是基于什么复制的？
是基于binlog复制的！这里不想去搬binlog的概念了，就简单理解为binlog是一个记录数据库更改的文件吧～
binlog有几种格式？
OK，三种，分别是

  • statement:记录的是修改SQL语句
  • row：记录的是每行实际数据的变更
  • mixed：statement和row模式的混合

那Mysql在5.0这个版本以前，binlog只支持STATEMENT这种格式！而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别！
接下来，就要说说当binlog为STATEMENT格式，且隔离级别为读已提交(Read Commited)时，有什么bug呢？如下图所示，在主(master)上执行如下事务
mysql事务的搬砖以及理解
此时在主(master)上执行下列语句

select * from test；

输出如下

+---+
| b |
+---+
| 3 |
+---+
1 row in set

但是，你在此时在从(slave)上执行该语句，得出输出如下

Empty set

这样，你就出现了主从不一致性的问题！原因其实很简单，就是在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式，它记录的顺序为先插后删！从(slave)同步的是binglog，因此从机执行的顺序和主机不一致！就会出现主从不一致！

原因：
（1）在rc隔离级别下，事务没有gap lock锁，因此可以在小于等于5的范围内插入一条新记录。
（2）binlog为statement记录的是master上产生的sql语句，按提交顺序记录的，因此binlog中记录的是先插入数据，后删除数据。（虽然master上是先删除数据后插入数据），逻辑上产生了不一致。
如何解决：
只需要解决上述问题中的一个就能保证数据的同步了。
（1）可以使用rr隔离级别；
（2）使用row格式的binlog；

gap lock 补充说明：当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。

举例来说，假如user表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：

select * from  user where user_id > 100 for update;

是一个范围条件的检索，InnoDB不仅会对符合条件的user_id值为101的记录加锁，也会对user_id大于101（这些记录并不存在）的“间隙”加锁。

InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了user_id大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要

总结

缘由一：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！

缘由二：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行

缘由三：在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！

在5.1.15的时候，innodb引入了一个概念叫做“semi-consistent”，减少了更新同一行记录时的冲突，减少锁等待。
所谓半一致性读就是，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)！

总结一句屁话，ｒｃ隔离级别比ｒｒ低，死锁可能性低，不锁表只锁行。那ｒｃ级别下不可重复读怎么处理。不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle的默认隔离级别就是RC，你们改过Oracle的默认隔离级别么？离开剂量谈毒性都是扯淡！！！

相关推荐