MySQL——1、事务

1.1 *事务*

1.1.1 *事务四个基本特征或 ACID 特性。*

事务是并发控制的单位，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。

一个转账必须 A账号扣钱成功，B账号加钱成功，才算正真的转账成功。

事务必须满足四大特征:原子性,一致性,隔离性持久性/持续性

原子性：表示事务内操作不可分割。要么都成功、要么都是失败.

一致性：要么都成功、要么都是失败.后面的失败了要对前面的操作进行回滚。

隔离性：一个事务开始后，不能后其他事务干扰。

持久性/持续性：表示事务开始了，就不能终止。

1.1.2 *事务概念*

1.1.2.1 *事务特性*

事务有四个特性，通常是ACID特性：

a 原子性

c 一致性

i 隔离性

d 持久性

具体解释如下：

1.1.2.2 *事务并发问题*

1.脏读

2.不可重复度

3.幻|虚读

不可重复读是两次读到的结果不一致，查询的一条数据中的内容不一致

虚读或幻读是两次查询的结果不一致，多出了一条数据

1.1.2.3 *事务的隔离级别*

Sql中的隔离级别如下：

读未提交

读已提交（oracle默认级别）

可重复读(mysql默认级别)

串行化 - 没有问题，但性能差一点

2 *事务传播行为的类型*

3 *M**ysql事务的隔离级别*

https://blog.csdn.net/justlpf/article/details/106837466

4 *Spring事务的隔离级别*

\1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，即使用数据库默认的事务隔离级别.如果是mysql，即可以防止脏读和不可重复读，不可访问幻读

另外四个与JDBC的隔离级别相对应

\2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。

这种隔离级别会产生脏读，不可重复读和幻像读。

\3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据

\4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。

它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。

\5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。

除了防止脏读，不可重复读外，还避免了幻像读。

其中的一些概念的说明：

脏读: 指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另外一 个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

不可重复读: 指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。 那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

幻觉读: 指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及 到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

4.0.1 *M**ysql事务是什么时候开启的*

MySQL 提供了多种存储引擎来支持事务。支持事务的存储引擎有 InnoDB 和 BDB，其中，InnoDB 存储引擎事务主要通过 UNDO 日志和 REDO 日志实现，MyISAM 存储引擎不支持事务。

为了维护 MySQL 服务器，经常需要在 MySQL 数据库中进行日志操作：

UNDO 日志：复制事务执行前的数据，用于在事务发生异常时回滚数据。

REDO 日志：记录在事务执行中，每条对数据进行更新的操作，当事务提交时，该内容将被刷新到磁盘。

默认设置下，每条 SQL 语句就是一个事务，即执行 SQL 语句后自动提交。为了达到将几个操作做为一个整体的目的，需要使用 BEGIN 或 START TRANSACTION 开启一个事务，或者禁止当前会话的自动提交。

sql语句中：

BEGIN WORK开始事务发出SQL命令

如果有任何错误，那么问题ROLLBACK命令，否则发出COMMIT命令。

4.0.2 *Redo/Undo机制*

原子性是基于日志的Redo/Undo机制

Redo log用来记录某数据块被修改后的值，可以用来恢复未写入 data file 的已成功事务更新的数据；Undo log是用来记录数据更新前的值，保证数据更新失败能够回滚

假如数据库在执行的过程中，不小心崩了，可以通过该日志的方式，回滚之前已经执行成功的操作，实现事务的一致性。

4.0.3 *Redo/Undo机制具体的实现流程*

假如某个时刻数据库崩溃，在崩溃之前有事务A和事务B在执行，事务A已经提交，而事务B还未提交。当数据库重启进行 crash-recovery 时，就会通过Redo log将已经提交事务的更改写到数据文件，而还没有提交的就通过Undo log进行roll back。

4.0.4 *MVCC（多版本并发控制）的原理*

在实现MVCC时用到了一致性视图，用于支持读提交和可重复读的实现

在实现可重复读的隔离级别，只需要在事务开始的时候创建一致性视图，也叫做快照，之后的查询里都共用这个一致性视图，后续的事务对数据的更改是对当前事务是不可见的，这样就实现了可重复读。

而读提交，每一个语句执行前都会重新计算出一个新的视图，这个也是可重复读和读提交在MVCC实现层面上的区别

快照（视图）在MVCC底层是怎么工作的吗

在InnoDB 中每一个事务都有一个自己的事务id，并且是唯一的，递增的

对于Mysql中的每一个数据行都有可能存在多个版本，在每次事务更新数据的时候，都会生成一个新的数据版本，并且把自己的数据id赋值给当前版本的row trx_id