事务:综合

参考文章

面试问烂的 MySQL 四种隔离级别,看完吊打面试官!

面试官:MySQL的可重复读级别能解决幻读问题吗? 

面试官再问数据库事务,把这篇文章发给他!

MySQL事务的实现原理

阿粉带你搞懂事务,事务隔离级别,事务传播行为之间的关系

MySQL事务的实现原理

面试官:你说对MySQL事务很熟?那我问你10个问题

一文快速搞懂MySQL InnoDB事务ACID实现原理

面试中的老大难-mysql事务和锁,一次性讲清楚!

mysql事务和事务隔离机制

搞清楚MySQL事务隔离级别

一文讲透事务、事务隔离级别、事务传播行为之间的关系

必须懂的 MySQL 的事务与隔离级别

数据库事务和四种隔离级别

MySQL 可重复读,差点背上一个 P0 事故!

阿里巴巴为什么要禁止使用存储过程?

事务 ACID

事务是逻辑上的一组操作,要么都执行,要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账1000元,

这个转账会涉及到两个关键操作就是:将小明的余额减少1000元,将小红的余额增加1000元。

万一在这两个操作之间突然出现错误比如银行系统崩溃,导致小明余额减少而小红的余额没有增加,

这样就不对了。事务就是保证这两个关键操作要么都成功,要么都要失败

  1. 原子性:事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;
  2. 一致性:执行事务前后,数据保持一致,多个事务对同一个数据读取的结果是相同的;
  3. 隔离性:并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的;
  4. 持久性:一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响

并发事务带来哪些问题?

在典型的应用程序中,多个事务并发运行,经常会操作相同的数据来完成各自的任务(多个用户对统一数据进行操作)。

并发虽然是必须的,但可能会导致以下的问题。

脏读(Dirty read):

当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,

这时另外一个事务也访问了这个数据,然后使用了这个数据。

因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。

丢失修改(Lost to modify):

指在一个事务读取一个数据时,另外一个事务也访问了该数据,

那么在第一个事务中修改了这个数据后,第二个事务也修改了这个数据。

这样第一个事务内的修改结果就被丢失,因此称为丢失修改。

例如:

事务1读取某表中的数据A=20,事务2也读取A=20,

事务1修改A=A-1,事务2也修改A=A-1,最终结果A=19,事务1的修改被丢失。

不可重复读(Unrepeatableread):

指在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。

那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。

这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。

幻读(Phantom read):

幻读与不可重复读类似。

它发生在一个事务(T1)读取了几行数据,接着另一个并发事务(T2)插入了一些数据时。

在随后的查询中,第一个事务(T1)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。

不可重复度和幻读区别:

不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改,

幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

SQL 标准定义了四个隔离级别:

READ-UNCOMMITTED(读取未提交)

最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。

READ-COMMITTED(读取已提交):

允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。

REPEATABLE-READ(可重复读):

对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,

可以阻止脏读和不可重复读,但幻读仍有可能发生。

SERIALIZABLE(可串行化):

最高的隔离级别,完全服从ACID的隔离级别。

所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。

隔离级别 脏读 不可重复读 幻影读
READ-UNCOMMITTED
读取未提交
READ-COMMITTED
读取已提交
×
REPEATABLE-READ
可重复读
× ×
SERIALIZABLE
可串行化
× × ×
 

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读)。

我们可以通过SELECT @@tx_isolation;命令来查看

这里需要注意的是:

与 SQL 标准不同的地方在于 InnoDB 存储引擎在 REPEATABLE-READ(可重读)事务隔离级别下使用的是Next-Key Lock 锁算法,

因此可以避免幻读的产生,这与其他数据库系统(如 SQL Server)是不同的。

所以说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读) 已经可以完全保证事务的隔离性要求,

即达到了 SQL标准的SERIALIZABLE(可串行化)隔离级别。

因为隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):,

但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ(可重读)并不会有任何性能损失。

InnoDB 存储引擎在 分布式事务 的情况下一般会用到SERIALIZABLE(可串行化)隔离级别

多版本并发控制(Multi-Version Concurrency Control, MVCC

多版本并发控制(Multi-Version Concurrency Control, MVCC),MVCC在每行记录后面都保存有两个隐藏的列,用来存储创建版本号和删除版本号。

创建版本号:创建一个数据行时的事务版本号(事务版本号:事务开始时的系统版本号;系统版本号:每开始一个新的事务,系统版本号就会自动递增);

删除版本号:删除操作时的事务版本号;

各种操作:

插入操作时,记录创建版本号;

删除操作时,记录删除版本号;

更新操作时,先记录删除版本号,再新增一行记录创建版本号;

查询操作时,要符合以下条件才能被查询出来:删除版本号未定义或大于当前事务版本号(删除操作是在当前事务启动之后做的);创建版本号小于或等于当前事务版本号(创建操作是事务完成或者在事务启动之前完成)

通过版本号减少了锁的争用,提高了系统性能;可以实现提交读和可重复读两种隔离级别,未提交读无需使用MVCC

三分钟图解 MVCC,看一遍就懂

谈谈对MySQL的MVCC的理解

关于MVCC,我之前写错了,这次我改好了!

 

 

posted @ 2019-12-12 22:26  弱水三千12138  阅读(186)  评论(0编辑  收藏  举报