mysql事务隔离机制及其原理

目录

• 事务特性ACID属性
• 并发事务带来的问题
• 事务隔离级别
• 事务实现原理
• 闲聊
• 【迈莫coding】

事务特性ACID属性

事务特性指的就是ACID，如图所示:

在这里插入图片描述

• 原子性 Atomicity ：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
• 一致性 Consistency ：在事务开始和完成时，数据必须保持一致。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。
• 隔离性 Isolation ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
• 持久性 Durability ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

并发带来的问题

• 更新丢失(Lost Updated)
  当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题，也就是最后的更新会覆盖掉先前的更新操作。
• 脏读(Dirty Reads)
  • 一个事务正在对一条记录进行修改时，在这个事务完成并提交之前，这条记录的数据就会处于不一致的状态；这时，另一个事务来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此进行进一步操作，就会产生未提交的数据依赖关系。这种现象被称为"脏读"。
    一句话：事务A读取了事务B已经修改但未提交的数据，如果事务B进行回滚，事务A读取的数据无效，不符合一致性。
• 不可重复读(Non-Repeatable Reads)
  • 一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读取的数据发生了改变，或者这些数据被删除，这种现象被称为"不可重复读"。
    一句话：事务A读取事务B提交的修改数据，不符合隔离型。
• 幻读(Phantom Reads)
  • 一个事务按照相同的查询条件重新读取以前检索的记录，却发现其他的事务插入满足查询条件的记录，这种现象被称为"幻读"。
    一句话：事务A读取事务B提交的新增数据，不符合隔离型。

事务隔离级别

上述所说的"脏读"，"不可重复读"，"幻读"这些问题，其实就是数据库读一致性问题，必须由数据库提供的事务隔离机制来进行解决。

在这里插入图片描述

mysql默认事务隔离级别为可重复读(RR)

数据库的事务隔离越严格，并发副作用越小，但付出的代价越大；因为事务隔离本质就是使事务在一定程度上处于串行状态，这本身就是和并发相矛盾的。

同时，不同的应用对读一致性和事务隔离级别是不一样的，比如许多应用对数据的一致性没那么个高要求，相反，对并发有一定要求。

事务实现原理

事务的实现是基于数据库的存储引擎。 不同的存储引擎对事务的支持不一样，接下来以mysql数据库中InnoDB引擎来解说.

InnoDB引擎是mysql的默认存储引擎，隔离级别为不可重复读(RR)，并在在RR隔离级别下通过MVCC解决不可重复读问题，通过间隙锁解决幻读问题。因此，InnoDB的RR隔离级别实现了串行化级别的效果，而且还保留了很好的并发性能。

事务隔离性是通过锁来实现的，而事务的原子性，一致性和持久性都是事务日志来实现的。 也就redo log日志和undo log日志，如果想看详细的日志介绍，请看我先前的文章<<校招mysql那些事儿|日志模块binlog/redolog/undolog>> 校招mysql那些事儿|日志模块binlog/redolog/undolog，这里只粗略的介绍redo log和undo log如何实现事务的原子性，一致性和持久性

• redo log

  • redo log被称为重写日志；事务日志通过redo log和innoDB引擎的日志缓冲(InnoDB Log Buffer)实现在事务开启的时候，事务的操作，都会写入redo log日志中，进而写入到InnoDB存储引擎的日志缓冲中，在事务提交前，这些缓冲日志都会提前刷新到磁盘上进行持久化，这也是mysql老提的WAL技术。
  • 在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

• undo log

  • undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。
  • undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。
  • 单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

以下是undo+redo事务的简化过程

1. 假设有2个数值，分别为A和B,值为1，2
2. start transaction;
3. 记录 A=1 到undo log;
4. update A = 3；
5. 记录 A=3 到redo log；
6. 记录 B=2 到undo log；
7. update B = 4；
8. 记录B = 4 到redo log；
9. 将redo log刷新到磁盘
10. commit

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。

闲聊

• 读完文章，自己是不是和mysql事务的cp率又提高了
• 我是迈莫，欢迎大家和我交流

文章也会持续更新，可以微信搜索「 迈莫coding 」第一时间阅读。