目录

1.原子性和持久性

1.1.手动提交事务

1.2.自动提交事务

 1.3.事务的原理：

2.隔离性

1.读未提交（Read Uncommitted）

 2.读提交（Read Committed）

3.可重复读

4.串行化

3.一致性

4.理解读提交和可重复读的实现原理区别

4.1.模拟 MVCC

4.2.read view

4.3.RR 与 RC的本质区别

---

事务的4大属性：原子性，持久性，隔离性，一致性；

在mysql中只有innodb支持事务，myisam是不支持事务的；

事务的作用：

1. 由于事务的隔离性，多个用户同时访问数据库时不必担心相互之间的影响，提高并发性和数据安全性；
2. 事务的提交和回滚操作还可以保证数据的安全性和完整性；

1.原子性和持久性

1.1.手动提交事务

1.事务的基本操作 

1. 使用begin或者start transaction,创建事务
2. 中间可以增删改操作
3. 使用commit提交事故 

2.创建保存点和回滚操作

• savepoint  标记；
• rollback to  标记：回滚到标记位置；rollback回滚到事务开头（begin位置）

只要事务未提交（未commit）就可以使用回滚操作 

1.2.自动提交事务

查看自动提交事务状态：
    show variables like 'autocommit';
设置为关闭：
    SET AUTOCOMMIT=0; 
设置为开启：
    SET AUTOCOMMIT=1; 

由下图可以得出：

1. 自动提交事务是对输入单条sql语句（不使用手动提交的情况）做自动提交；
2. 如果关闭自动提交，那么单条sql不会被写入磁盘，保证原子性； 

 1.3.事务的原理：

原子性：要么做完，要么不做，没有中间态 ；可以分为3个状态，执行前，执行中，执行后；

1.事务的3个状态可以为：

• 执行前：使用begin从磁盘中把数据拿到内核缓冲区，再从内核缓冲区拷贝到用户层的buffer pool中，简单的说就是把磁盘数据保存到内存的用户层的缓冲区；
• 执行中：使用sql语句对拿到内存中数据进行增删改；
• 执行后：使用commit把修改的内存数据，拿到磁盘去；

如何保证的原子性：如果不使用commit交付数据，事务结束后就自动会回滚到执行前，使用commit交付数据那么就是执行后

持久性是什么：就是已经交付的数据（commit），就会保存在磁盘中且不受回滚的约束

2.隔离性

• MySQL服务可能会同时被多个客户端进程(线程)访问，访问的方式以事务方式进行（并发执行）
• 数据库中，为了保证事务并发执行过程中尽量不受干扰，就有了一个重要特征：隔离性
• 在不同的场景需要不同的隔离级别：有4种，读未提交、读提交、可重复读、串行化

查看设置隔离级别：

select @@global.tx_isolation;查看全局隔离级别

select @@session.tx_isolation;查看会话隔离级别

设置隔离等级格式：set session/global transaction isolation level read uncommitted/read committed/repeatable read/serializable; //全局和会话选一个，隔离等级4选1；

设置会话隔离等级

1.读未提交（Read Uncommitted）

在该隔离级别，所有的事务都可以看到其他事务没有提交的执行结果。（实际生产中不可能使用这种隔离级别的），但是相当于没有任何隔离性，也会有很多并发问题；（脏读，幻读，不可重复读）；

脏读：一个事务进行增删改，另一个正在执行的事务可以读取到未提交（commit）的数据； 

脏读的问题举例：要对查询到表的多条记录发奖励，另外一个事务新增了一行记录且没有提交，那么奖励多发一个； 

 2.读提交（Read Committed）

该隔离级别是大多数数据库的默认的隔离级别（不是 MySQL 默认的）。它满足了隔离的简单定义:一个事务只能看到其他的已经提交的事务所做的改变，有不可重复读的问题

不可重复读：多个事务并发执行，一个事务增/删/改一条数据且提交，其他的正在执行的事务就可以看到这条数据；

不可重复的问题举例：我们按分数发奖励，100分发100块钱，90分发50块钱，80分发30块，小明得了100分，在比较100分的时候给他发100块，在比较90分的时候入过另一个事务把小明改为90分并且提交，那么小明又可以得到50块，那么就出问题了

 

3.可重复读

概念：这是MySQL默认的隔离级别，它确保同一个事务，在执行中，多次读取操作数据时，会看到同样的数据行。但是一般数据库会有幻读问题，mysql没有这个问题被解决了

幻读：这一系列隔离都是加锁完成的，但是新增的数据没到磁盘一般锁不能限制，所以其他事务插入，查询时会看到新增数据，mysql是使用Next-Key锁(GAP+行锁)解决的；

 

4.串行化

 概念：: 这是事务的最高隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决了 幻读的问题。它在每个读的数据行上面加上共享锁。但是可能会导致超时和锁竞争（这种隔离级别太极端， 实际生产基本不使用）

3.一致性

例如转账问题A有1000￥，B有800￥，A给B转账200￥，A有800￥B拥有1000￥；

一致性的概念：事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。A有1000B有800是一个一致性状态，A有800B有1000是另一个一致性状态；

如何保证转账成功呢，防止A转账了，B没有收到了，

1. 有回滚和提交这种方法（原子性），保护已经修改的数据不会回滚（持久性），并发执行不受影响（隔离性）；
2. 用户对A和B的数据修改

由上可得：一致性并没有具体的实例，是由用户和mysql的特性来共同来维护的概念

4.理解读提交和可重复读的实现原理区别

数据库并发的场景有三种：

• 读读：不存在任何问题，也不需要并发控制；
• 读写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写写：有线程安全问题，可能会存在更新丢失问题

读写

多版本并发控制（ MVCC ）是一种用来解决 读-写冲突 的无锁并发控制

4个记录隐藏列字段：

• DB_TRX_ID ：6 byte，最近修改( 修改/插入 )事务ID，记录创建这条记录/最后一次修改该记录的事务ID，识别不同事务身份；
• DB_ROLL_PTR : 7 byte，回滚指针，指向这条记录的上一个版本（简单理解成，指向历史版本就行，这些数据一 般在 undo log 中）
• DB_ROW_ID : 6 byte，隐含的自增ID（隐藏主键），如果数据表没有主键， InnoDB 会自动以 DB_ROW_ID 产生一 个聚簇索引
• 删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了,flag=0未删，flag=1已删除（内存）

加上隐藏列: 

undo日志

• 是一个内存缓冲区，用来保存日志数据；

4.1.模拟 MVCC

修改张三这行记录的过程

• 事务10,因为要修改，所以要先给该记录加行锁。
• 修改前，现将改行记录拷贝到undo log中，所以，undo log中就有了一行副本数据。(原理就是写时拷贝)
• 所以现在 MySQL 中有两行同样的记录。现在修改原始记录中的name，改成 '李四'。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前 事务10 的ID, 我们默认从 10 开始，之后递增。而原始记录的回滚指针 DB_ROLL_PTR 列， 里面写入undo log中副本数据的地址，从而指向副本记录，既表示我的上一个版本就是它
• 事务10提交，释放锁。

现在有一个事务11，要对当前记录的age修改为38；

 这样，我们就有了一个基于链表记录的历史版本链。所谓的回滚，无非就是用历史数据，覆盖当前数据。

• 上面的一个个版本，我们可以称之为一个个的快照。

1. 当前读：读取最新的记录，就是当前读。增删改，都叫做当前读，select也有可能当前读，比如：select lock in share mode(共享锁), select for update
2. 快照读：读取历史版本(一般而言)，就叫做快照读。

4.2.read view

read view是一个类（mysql1使用c++实现），下面是它的一部分；

class ReadView {
// 省略...
private:

/** 高水位，大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id

/** 低水位：小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;

/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;

/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
//省略...
};

1. 无论是读提交还是可重复读都遵守下面的概念；它们两的区别不在这里，所以不要想着它们的概念来理解下面的图，反而更难理解
2. 由read view来决定可不可读，形成快照后分为3部分，第一部分都可读，第二部分提交的就可读，第三部分都不可读；

• 第一部分：creator_limit_id==DB_TRX_ID就是自己的事务id当然可读，DB_TRX_ID<up_limit_id说明不在这个m_ids（活跃事务id列表）范围之内，而且因为事务id自增长的，比最小活跃事务还小说明它以前已经提交的；
• 第二部分：up_limit_id到low_limit_id之间；不就是m_ids里面的活跃事务吗；那么已经提交的可读，未提交不可读（这里不是不可重复读问题，读提交和可重复读都支持read view来决定可不可读概念，下面说明它们的区别是读提交每次快照读就会生成一个新的read view，可重复读快照读生成一个read view就不会再生成了）；
• 第三部分：DB_DRX_ID>=low_limit_id,比m_ids的所以活跃事务都大，那么是不可读的；

4.3.RR 与 RC的本质区别

可重复读隔离等级下

 

•  用例1与用例2：唯一区别仅仅是 表1 的事务B在事务A修改age前 快照读 过一次age数据
• 而表2的事务B在事务A修改age前没有进行过快照读。

RR 与 RC的本质区别：

• 正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同
• 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来（m_ids）
• RR级别此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用（活跃事务）过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改（第三部分）不可见；
• 而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以 看到别的事务提交的更新的原因
• 在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务 中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。
• 正是RC每次快照读，都会形成Read View，所以，RC才会有不可重复读问题。