快捷搜索:  汽车  科技

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务) 1、读未提交:不同隔离级别的锁的情况(了解)4种事务隔离级别从上往下,级别越⾼,并发性越差,安全性就越来越⾼。 ⼀般数据默认级别是 读已提交或可重复读。InnoDB默认是可重复读级别的简单点总结下他们的区别:脏读是指读取了未修改完的记录,不可重复读指因为被其它事务修改了记录导致某事务两次读取记录不一致,而幻读是指因为其它事务对表做了增删导致某事务两次读取的表记录数不一致问题。

在技术面试中,面试官经常能够问到关于数据库事务相关的,今天我们就来讲讲什么是事务及事务相关的知识点。

什么是事务?

MySQL 事务主要用于处理操作量大,复杂度高的数据。比如说,在人员管理系统中,你删除一个人员,你既需要删除人员的基本资料,也要删除和该人员相关的信息,如信箱,文章等等,这样,这些数据库操作语句就构成一个事务!

  • 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。
  • 事务处理可以用来维护数据库的完整性,保证成批的 SQL 语句要么全部执行,要么全部不执行。
  • 事务用来管理 insert update delete 语句

一般来说,事务是必须满足4个条件(ACID):

原子性(Atomicity,或称不可分割性)、一致性(Consistency)、隔离性(Isolation,又称独立性)、持久性(Durability)

  • 原子性:一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
  • 一致性:在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
  • 隔离性:数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。
  • 持久性:事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
MySQL事务隔离级别

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(1)

4种事务隔离级别从上往下,级别越⾼,并发性越差,安全性就越来越⾼。 ⼀般数据默认级别是 读已提交或可重复读。

InnoDB默认是可重复读级别的

  • ① 脏读: 脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。
  • ② 不可重复读:是指在一个事务内,多次读同一数据。在这个事务还没有结束时,另外一个事务也访问该同一数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的,因此称为是不可重复读。
  • ③ 幻读:第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好像发生了幻觉一样,幻读是数据行记录变多了或者少了。

简单点总结下他们的区别:脏读是指读取了未修改完的记录,不可重复读指因为被其它事务修改了记录导致某事务两次读取记录不一致,而幻读是指因为其它事务对表做了增删导致某事务两次读取的表记录数不一致问题。

不同隔离级别的锁的情况(了解)

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(2)

用例子说明各个隔离级别的情况

 1、读未提交:

(1)打开一个客户端A,并设置当前事务模式为read uncommitted(未提交读),查询表account的初始值:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(3)

(2)在客户端A的事务提交之前,打开另一个客户端B,更新表account:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(4)

(3)这时,虽然客户端B的事务还没提交,但是客户端A就可以查询到B已经更新的数据:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(5)

(4)一旦客户端B的事务因为某种原因回滚,所有的操作都将会被撤销,那客户端A查询到的数据其实就是脏数据:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(6)

(5)在客户端A执行更新语句update account set balance = balance - 50 where id =1,lilei的balance没有变成350,居然是400,是不是很奇怪,数据不一致啊,如果你这么想就太天真 了,在应用程序中,我们会用400-50=350,并不知道其他会话回滚了,要想解决这个问题可以采用读已提交的隔离级别

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(7)

2、读已提交

(1)打开一个客户端A,并设置当前事务模式为read committed(未提交读),查询表account的初始值:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(8)

(2)在客户端A的事务提交之前,打开另一个客户端B,更新表account:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(9)

(3)这时,客户端B的事务还没提交,客户端A不能查询到B已经更新的数据,解决了脏读问题:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(10)

(4)客户端B的事务提交

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(11)

(5)客户端A执行与上一步相同的查询,结果 与上一步不一致,即产生了不可重复读的问题

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(12)

3、可重复读

(1)打开一个客户端A,并设置当前事务模式为repeatable read,查询表account

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(13)

(2)在客户端A的事务提交之前,打开另一个客户端B,更新表account并提交

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(14)

(3)在客户端A执行步骤(1)的查询:

四个案例看懂mysql事务隔离级别(一文讲透MySQL之事务)(15)

(4)执行步骤(1),lilei的balance仍然是400与步骤(1)查询结果一致,没有出现不可重复读的 问题;接着执行update balance = balance - 50 where id = 1,balance没有变成400-50=350,lilei的balance值用的是步骤(2)中的350来算的,所以是300,数据的一致性倒是没有被破坏,这个有点神奇,也许是mysql的特色吧,虽然可重复读解决了两次读取数据的一致性,但是数据并不准确,实际开发中必须手动加行级锁,只有更新完成后才能继续读取,避免数据操作出错

mysql> select * from account; ------ -------- --------- | id | name | balance | ------ -------- --------- | 1 | lilei | 400 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | ------ -------- --------- 3 rows in set (0.00 sec) mysql> update account set balance = balance - 50 where id = 1; Query OK 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; ------ -------- --------- | id | name | balance | ------ -------- --------- | 1 | lilei | 300 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | ------ -------- --------- 3 rows in set (0.00 sec)

(5) 在客户端A提交事务,查询表account的初始值

mysql> commit; Query OK 0 rows affected (0.00 sec) mysql> select * from account; ------ -------- --------- | id | name | balance | ------ -------- --------- | 1 | lilei | 300 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | ------ -------- --------- 3 rows in set (0.00 sec)

(6)在客户端B开启事务,新增一条数据,其中balance字段值为600,并提交

mysql> start transaction; Query OK 0 rows affected (0.00 sec) mysql> insert into account values(4 'lily' 600); Query OK 1 row affected (0.00 sec) mysql> commit; Query OK 0 rows affected (0.01 sec)

(7) 在客户端A计算balance之和,值为300 16000 2400=18700,没有把客户端B的值算进去,客户端A提交后再计算balance之和,居然变成了19300,这是因为把客户端B的600算进去了

,站在客户的角度,客户是看不到客户端B的,它会觉得是天下掉馅饼了,多了600块,这就是幻读,站在开发者的角度,数据的 一致性并没有被破坏。但是在应用程序中,我们的代码可能会把18700提交给用户了,如果你一定要避免这情况小概率状况的发生,那么就要采取下面要介绍的事务隔离级别“串行化”

mysql> select sum(balance) from account; -------------- | sum(balance) | -------------- | 18700 | -------------- 1 row in set (0.00 sec) mysql> commit;Query OK 0 rows affected (0.00 sec) mysql> select sum(balance) from account; -------------- | sum(balance) | -------------- | 19300 | -------------- 1 row in set (0.00 sec)

4.串行化

(1)打开一个客户端A,并设置当前事务模式为serializable,查询表account的初始值:

mysql> set session transaction isolation level serializable; Query OK 0 rows affected (0.00 sec) mysql> start transaction; Query OK 0 rows affected (0.00 sec) mysql> select * from account; ------ -------- --------- | id | name | balance | ------ -------- --------- | 1 | lilei | 10000 | | 2 | hanmei | 10000 | | 3 | lucy | 10000 | | 4 | lily | 10000 | ------ -------- --------- 4 rows in set (0.00 sec)

(2)打开一个客户端B,并设置当前事务模式为serializable,插入一条记录报错,表被锁了插入失败,mysql中事务隔离级别为serializable时会锁表,因此不会出现幻读的情况,这种隔离级别并发性极低,开发中很少会用到。

mysql> set session transaction isolation level serializable; Query OK 0 rows affected (0.00 sec) mysql> start transaction; Query OK 0 rows affected (0.00 sec) mysql> insert into account values(5 'tom' 0); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

补充:

  1、SQL规范所规定的标准,不同的数据库具体的实现可能会有些差异

  2、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行

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

  4、事务隔离级别为可重复读时,如果有索引(包括主键索引)的时候,以索引列为条件更新数据,会存在间隙锁间隙锁、行锁、下一键锁的问题,从而锁住一些行;如果没有索引,更新数据时会锁住整张表。

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

   6、隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大,鱼和熊掌不可兼得啊。对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为Read Committed,它能够避免脏读取,而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁或乐观锁来控制。

猜您喜欢: