MySQL事务管理
目录
认识事务
事务的概念
事务的四大特性
支持事务的数据库引擎
事务的提交方式
事务的相关演示
事务的隔离级别
查看与设置隔离级别
读未提交（Read Uncommitted）
读提交（Read Committed）
可重复读（Repeatable Read）
串行化（Serializable）
隔离级别总结
一致性的理解
多版本并发控制
记录中的3个隐藏字段
undo日志
画图理解MVCC
Read View
RR与RC的本质区别
认识事务
事务的概念
概念：
事务是一组操作，这些操作要么全部执行成功，要么全部失败回滚。
解释：
1.操作的意思就是一条或多条SQL语句组成，这些语句在逻辑上存在相关性，共同完成一个任务。
2.而操作要么全执行成功，要么全失败回滚的属性就是事务的原子性，除此之外事务还有持久性、隔离性、一致性。
为什么出现事务？
解决用户访问数据库的潜在问题，比如网络异常，服务器宕机，数据不一致，并发冲突，数据丢失。
事务的四大特性
原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中如果发生错误，则会自动回滚到事务开始前的状态，不会对数据库产生任何影响。
持久性（Consistency）：事务提交后，对数据库的修改就是永久的，即使系统崩溃也将保存在数据库中。
隔离性（Isolation）：数据库允许多个事务同时访问同一份数据，隔离性保证事务在并发执行和串行结果一致。
一致性（Durability）：在事务的开始和结束，数据库的完整性约束必须得到保持。
支持事务的数据库引擎
说明：
Engine：存储引擎的名称。
Support：服务器对存储引擎的支持级别，YES表示支持，NO表示不支持，DEFAULT表示数据库默认使用的存储引擎。
Comment：存储引擎的简要说明。
Transaction：表示存储引擎是否支持事务，可以看到MySQL中只有InnoDB存储引擎支持事务。
XA：表示存储引擎是否支持XA事务。
Savepoints：表示存储引擎是否支持保存点。
事务的提交方式
事务常见的提交方式有两种，分别是自动提交和手动提交。
通过show variables like 命令查看全局变量 autocommit，可以查看事务的自动提交是否被打开：
ON表示自动提交打开，OFF表示自动提交关闭。
用 SET 来改变 MySQL 的自动提交模式。
事务的相关演示
演示1：事务的开始和回滚
执行下面SQL：
//1.建表
//2.查看提交方式
//3.开始事务
//4.设置保存点1
//5.插入数据1
//6.设置保存点2
//7.插入数据2
//8.查看数据
//9.回滚到保存点2
//10.查看数据，数据2消失了
//11.回滚到最初
//12.查找数据，数据1也消失了
create table if not exists account(
id int primary key,
name varchar(50) not null default '',
blance decimal(10,2) not null default 0.0
)ENGINE=InnoDB DEFAULT CHARSET=UTF8;
show variables like 'autocommit';
start transaction;
savepoint save1;
insert into account values (1, '张三', 100);
savepoint save2;
insert into account values (2, '李四', 10000);
select * from account;
rollback to save2;
select * from account;
rollback;
select * from account;演示结果：rollback可以回滚到指定保存点或事务最开始的状态。
演示2：证明未commit，客户端崩溃，MySQL自动会回滚（隔离级别设置为读未提交）
执行SQL：
1.查看当前会话隔离级别
2.设置当前会话隔离级别为读未提交
3.查看表
4.开始事务
5.插入数据
6.提交事务
7.使用ctrl + 、异常终止MySQL
8.在终端B上查看表
select @@session.tx_isolation;
set session transaction isolation level READ UNCOMMITTED;
select * from account;
begin ;
insert into account values(1,'张三',100);
commit;
//终端B
select * from account;
输出：
异常终止终端A后在终端B仍然可以看到数据，可见commit的数据持久化了：
演示3：begin操作会自动更改提交方式（事务中的所有的SQL语句都需要显示使用COMMIT语句进行提交），不受MySQL是否自动提交影响
执行SQL：
修改自动提交为OFF，开启事务，往表插入数据，使用ctrl + \异常终止MySQL，在终端B查看数据是否回滚。
select * from account;
show variables like 'autocommit';
set autocommit=0;
show variables like 'autocommit';
begin;
insert into account values(2,'李四',10000);
select * from account;
//终端B
//终端A崩溃前
select * from account;
//终端A崩溃后
select * from account;输出：
演示4：证明单条SQL与事务的关系
执行SQL：
//实验一
select * from account;
show variables like 'autocommit';
set autocommit=0;
insert into account values(2,'李四',10000);
//终端B
//终端A崩溃前
select * from account;
//终端A崩溃后
select * from account;
//实验二
//终端A
show variables like 'autocommit';
set autocommit=1;
show variables like 'autocommit';
select * from account;
insert into account values(2,'李四',10000);
select * from account;
//终端B
//终端A崩溃前
select * from account;
//终端A崩溃后
select * from account;
做两个实验，一个是自动提交模式，一个是手动提交，验证数据的持久性。
实验一（手动提交），终端A：
实验一，终端B:(可见手动提交下，单条SQL不具有持久性）
实验二（自动提交），终端A：
实验二（自动提交），终端B：
结论总结：
1.begin或者start transaction开始的事务，事务便必须要通过commit提交，才会持久化，与是
否设置set autocommit无关。2.事务可以手动回滚，同时，当操作异常，MySQL会自动回滚。3.InnoDB 每一条 SQL 语言都默认封装成事务，自动提交。4.如果没有设置保存点，也可以回滚，只能回滚到事务的开始。直接使用 rollback(前提是事务还没有提交) 。
5.如果一个事务被提交了（commit），则不可以回退（rollback） 。6.事务执行中可以选择回退到哪个保存点。7.InnoDB 支持事务， MyISAM 不支持事务。
事务的隔离级别
基本概念：
脏读：一个事务在执行过程中读取到了另一个事务未提交的数据。
不可重复读：事务在执行过程中，读取到的某个数据后，另一个事务修改了该数据，导致第一个事务重新读取数据的结果不一致。
幻读：一个事务在读取某个范围的数据时，另一个事务插入了新的数据，导致第一个事务重新读取该范围的数据时，发现有新的数据出现。
读未提交【Read Uncommitted】：所有的事务都可以看到其他事务没有提交的执行结果。相当于没有隔离性，会导致脏读、幻读、不可重复读问题。
读提交【Read Commited】：该隔离级别的大多数数据库的默认隔离级别，在事务中只能看到其他的已经提交的事务所做的改变。这种隔离级别会引起不可重复读，即一个事务执行时，多次select可能结果不一样。
可重复读【Repeatable Read】：MySQL默认的隔离级别，确保同一个事物在执行中，多次读取操作数据时，会看到同样的数据行。但是会有幻读问题。
串行化【Serializable】事务的最高隔离级别，通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。它在每个读的数据行上加上共享锁，可能会导致超时和锁竞争（效率低）。
隔离级别如何实现：通过锁实现，常见锁有表锁、行锁、读锁、写锁、间隙锁（GAP）、Next-Key锁（GAP+行锁）等。
查看与设置隔离级别
查看全局隔离级别：
SELECT @@global.tx_isolation;
查看当前会话全局隔离级别：
SELECT @@session.tx_isolation;
查看隔离级别（默认同上）：
SELECT @@tx_isolation;
设置当前会话或全局隔离级别：
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERALIZABLE}
读未提交（Read Uncommitted）
设置全局隔离级别为读未提交，在终端A开启事务并更新指定行，在终端A提交事务前，在终端B看到了未commit的数据（即脏读）。
终端A：
终端B：
终端B的事务执行过程中读到了终端A更新但未commit的数据，属于脏读。
读提交（Read Committed）
设置全局隔离级别为读提交，在终端A开启事务并更新数据，在终端B开启事务并在终端A事务提交前后读取同一数据读到了不同的数据，即发生了不可重复读的现象。
终端A：
终端B：
在同一事务内，在不同时间段，读取到了不同的值，即不可重复读。
可重复读（Repeatable Read）
设置全局隔离级别为可重复读，在终端A开启事务，并更新数据，在终端B开启事务，并在终端A事务提交前后读取同一数据读到了相同的数据，即可重复读。将更新数据改成插入数据，再实验一次，发现没有发生读取数据也是读到了相同的数据，即没有发生幻读。
注意：设置隔离级别后要退出mysql客户端重新启动。
终端A：
终端B：
可见在终端A的事务提交前后，在终端B的事务中读取到的数据都是一致的，也即具有可重复读的性质。
倘若将update数据变成插入数据会如何：
终端A：
终端B：
可见还是满足了可重复读，没有出现幻读现象，这是因为MySQL在RR级别的时候，是解决了幻读问题的(解决的方式是用Next-Key锁 (GAP+行锁)解决的）。
注意：Next-Key锁 就是间隙锁和记录锁的组合。（源自MySQL官网）
串行化（Serializable）
设置全局隔离级别为串行化，其中终端A更新数据后，在终端B开启事务，并读取数据，发现阻塞住了，当终端A事务提交后，终端B才看到数据。
终端A：
终端B：
隔离级别总结
总结：
较低的隔离级别可以提高并发性能，但可能会引入数据一致性问题；而较高的隔离级别可以保证数据一致性，但可能降低并发性能。
不可重复读关注的是修改和删除：读取过的数据，再次读取处理就发现值不一样了。
幻读的重点在于新增：同样的条件，第一次和第二次读出来的记录数不一样。
MySQL默认的隔离级别是可重复读，也是兼顾数据一致性和并发性考虑的较优选择。
一致性的理解
事务在执行过程中，将数据库从一个一致的状态转换为另一个一致的状态。
一致性和用户业务逻辑强相关，MySQL提供技术支持，一致性还需要用户业务逻辑做支撑，也就是一致性由用户决定。技术上，有原子性、隔离性、持续性保证一致性。
多版本并发控制
数据库的并发场景有三种：
读-读：没有问题，不用并发控制。
读-写：有线程安全问题，可能会造成事务隔离性问题，即可能遇到脏读、幻读、不可重复读。
写-写：有线程安全问题，可能会存在更新丢失问题。
数据库的更新丢失问题是指在并发环境下，多个事务同时对同一数据进行更新操作时可能出现的问题。
MVCC（Multi-Version Concurrency Control）：多版本并发控制
多版本并发控制是一种用来解决读 - 写冲突的无锁并发控制。
为事务分配单向增长的事务ID，为每个修改保存一个版本，版本与事务ID关联，读操作只读该事务开始前的数据库的快照，所以MVCC可以为数据库解决下面问题：
并发读写时，读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。
解决脏读、幻读、不可重复读等事务隔离问题，但不能解决更新丢失问题。
记录中的3个隐藏字段
DB_TRX_ID：6byte，最近修改事务ID，记录创建这条记录/最后一次修改该记录的事务ID。
DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本
DB_ROW_ID：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引（数据行按照索引的顺序存储在磁盘上，具有相邻的物理位置）。
还有一个flag隐藏字段，记录这数据被更新或删除，记录删除只需标记flag即可。
undo日志
MySQL中的一段内存缓存区，用来保存日志数据。
画图理解MVCC
假设表中刚插入了一条记录如下，因为不知道创建该记录的事务ID，隐式主键，首条记录也没有回滚指针，所以将他们设置成默认值：
现在执行事务1，对表记录进行修改，修改张三名字为李四。
修改记录前，对记录加行锁，将原本记录拷贝到undo log中，然后写入新的数据，事务ID为1，回滚指针指向副本记录，表示新记录的上个版本就是它。
然后提交事务，释放锁。
事务1执行后：
现在再执行事务2，对表中记录进行修改，将age改成19.
修改记录前，对记录加行锁，将原本记录拷贝并头插入undo log中。
然后修改记录，事务ID为2，回滚指针指向上一个版本的记录。
提交事务2，释放锁。
事务2执行后：
于是我们就有了一个基于链表记录的历史版本链，回滚就是用版本链中的版本覆盖当前数据。
这个历史版本链不仅用于数据回滚，还用于其他事务读取历史版本，所以只有当前记录提交且其他事务与版本链无关的时候，该历史版本链才能删除。
插入和删除的时候如何维护版本链？
删除：将数据拷贝一份放入undo log中，并将该记录的隐藏flag删除字段置为1，这样回滚后flag字段又变成0，相当于删除的数据又恢复了。
插入：新插入的数据没有历史版本，为了回滚操作，新插入的数据拷贝一份放到undo log中，且undo log中的记录的flag标记为1，回滚后就相当于数据被删除了。
上面的一个个版本，我们可以称之为一个个快照。
概念：
快照读：读取历史版本的数据。
当前读：读取当前版本的数据。
事务对数据进行增删改的时候，操作的都是最新记录，即当前读，需要进行加锁保护。
事务在进行select查询的时候，既可能是当前读也可能是快照读，如果是当前读，那也需要进行加锁保护，但如果是快照读，那就不需要加锁，因为历史版本不会被修改，也就是可以并发执行，提高了效率，这也就是MVCC的意义所在。
Read View
Read View就是事务进行快照读操作时产生的读视图（Read View）。
在该事务执行的快照读的那一刻，会生成数据库系统当前的快照，记录并维护系统当前活跃事务的ID。（每个事务开启，都分配一个递增的ID，越新的事务，事务ID越大）
Read View在MySQL源码中是一个类，用来可见性判断的，判断当前事务能看到哪个版本的数据。
其基本组成如下：
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;
/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，
* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
// 省略...
};那么MVCC是如何实现的？
结合源码和画图理解：
画图理解：其中id就是下图的DB_TRX_ID
当进行快照读的时候就对比DB_TRX_ID和Read View中的水位线id即可。
当DB_TRX_ID即id等于创建该快照的id或小于up_limit_id那么该记录是可见的。（小于up_limit_id表示事务已提交）。
当id>=low_limit_id说明事务是快照生成后才提交的事务，则事务是不可见的。
当事务id在活跃事务id列表中时，表示事务在进行，也是不可见的。
RR与RC的本质区别
RR是可重复读，RC是读提交，前面提到，读提交是可以读到已经提交的事务的，是不可重复读的，而可重复读的隔离级别是能在一个事务中保证读取数据的一致性的。
RR和RC级别的不同，本质是Read View生成的时机不同。
在RR级别下某个事务对某条记录的第一次快照读会创建一个快照及Read View，将当前系统活跃的其他事务记录起来，此后再进行快照读的时候，使用的是同一个Read View，所以对之后的修改不可见，实现了读取数据的可重复读。
而在RC级别下，在事务中每一次快照读都会生成并获取最新的Read View，所以别的事务提交了，新的快照读也就马上能看到，所以RC具有不可重复读的问题。