一、概念
事务 个别指的是逻辑上的一组操作，或者作为单个逻辑单元执行的一系列操作，一个事务中的所有操作会被封装成一个不可分割的执行单元，这个单元的所有操作要么全副执行胜利，要么全副执行失败，只有其中任意一个操作执行失败，整个事务就会执行回滚操作。
二、事务的个性以及类型介绍
2.1 事务个性
原子性（atomicity）
事务的原子性指的是形成事务的所有操作要么全副执行胜利，要么全副执行是失败。
一致性（consistency）
事务的一致性指的是事务执行之前和执行之后，数据始终处于统一的状态。
隔离性（isolation）
事务的隔离性指的是并发执行的两个事务之间互不烦扰，也就是说，一个事务执行的过程中是无奈看到其余事务运行过程的中间状态的。
留神：MySQL是通过锁个MVCC机制来保障事务的隔离性。
持久性（duration）
事务的持久性指的是一旦事务被提交后，此事务对数据的更改操作会被长久化到数据库中，并且不会被回滚。
2.2 两种事务类型介绍
- 本地事务
- 分布式事务
本地事务
通常基于关系型数据库管制的事务能够称作为传统事务或者本地事务。
本地事务的执行流程
- 客户端开始事务操作之前，须要开启一个连贯回话；
- 开始回话之后，客户端发动开启事务的指令；
- 事务开始后，客户端发送各种SQL语句解决数据；
- 失常状况下，客户端会发动提交事务的指令，如果产生异常情况，客户端会发动回滚事务命令；
- 上述流程实现后，敞开会话。
✔本地事务是有资源管理器在本地进行治理的。
本地事务的毛病在于：
- 不具备分布式事务的解决能力
- 一次事务过程只能连贯一个反对事务的数据库，既不能用于多个事务性数据库。
三、并发事务会带来的哪些问题?
更新失落（脏写）
当两个会在两个以上的事务同时操作同一行数据，并给予最后选定的值更新该行数据时，视为事务之间是无奈感知彼此的存在的，所以会呈现最初的更新操作会笼罩之前其余事务实现的更新操作。
举个例子：
张三的账户为100元，以后有两个事务：事务1和事务2，事务1是将张三账户余额减少100元，事务2是将张三余额减少200，起初事务1和事务2同时读到张三的账户余额都是100元，而后事务1和事务2别离更新张三月，假如事务1先于事务2提交，然而最近两个事务都提交后张三的余额为300元（失常状况应该是400元），也就是说：后提交的事务2笼罩了事务1的更新操作，这就是所谓的更新失落，更新失落（脏写）实质上是写操作的抵触，然而解决脏写的形式是让每个事务串行形式执行，保障事务依照肯定的程序执行写操作。
脏读
一个事务读取到另一个事务未提交的数据。比方：事务1正在对张三的余额减少100元，在这个事务没提交之前，另一个事务2读取了正在批改的这条数据，如果没有事务的管制下，第二条事务就会读取到没有被提交的脏数据，并且对脏数据丛下一步的解决，此时就会产生未提交数据的依赖关系，通常这种景象被称为 脏读，也就是说：脏读是一个事务读取了另一个事务没提交的数据。
脏读实质上是读写操作的抵触，解决办法是先写后读，也就是写完之后再读。
不可反复读
一个事务读取了某些数据，在一段时间后，这个事务再次读取之前读过的数据，此时发现读取的数据产生了变动，或者其中某些数据记录曾经被删除，这种景象被称为：不可反复读，即同一个事务，应用同样的查问语句，在不同时刻读取到的后果不统一。
不可反复读的实质上也是读写操作抵触，解决办法是先读后写，也就是读完之后再写。
幻读
一个事务依照雷同的查问条件从新读取之前读过的数据，此时发现其余事务插入了满足以后查问条件的新数据，数据后果集变多，这种景象称为幻读，即一个事务两次读取一个范畴的数据记录，两次读到的后果不同。
幻读的实质上也是读写操作抵触，解决办法是先读后写，也就是读完之后再写。
那到这里，很多小伙伴就有疑难，同样实质都是读写操作抵触，解决办法是先读后写，不可反复读和幻读到底有何区别?，我上面见简略解释一下：
1️ 不可反复读的重点在于更新和删除操作，而幻读的重点在于插入操作。
2️ MySQL应用锁机制实现事务的隔离级别时，在可反复读隔离级别中，SQL语句第一个读取到数据后，会将相应的数据加锁，使得其余事务无奈批改和删除这些数据，通过锁的形式实现可反复读。然而这种办法无奈对新数据的插入加锁，如果事务1读取了数据，或者批改和删除了数据，事务2还能够进行插入操作，导致事务1莫名其妙地多了一条之前没有的数据，这就是幻读。
3️ 所以，幻读是无奈通过锁机制来防止，须要应用串行化的事务隔离级别，然而这种事务隔离级别会大大降低数据库的并发能力。
✔MySQL是通过MVCC（多版本并发管制）机制来防止不可反复读和幻读的。
四、MySQL事务的隔离级别
应用上面的命令能够查问全局级别和会话级别的事务隔离级别：
# 默认数据库的事务隔离级别为：可反复读（REPEATABLE-READ）SELECT @@global.tx_isolation;SELECT @@session.tx_isolation;SELECT @@tx_isolation;五、多版本并发管制MVCC
Multi-Version Concurrency Control多版本并发管制，MVCC是一种并发管制的办法，个别在数据库管理系统中，实现对数据库的并发拜访。
MVCC比锁的劣势
能够将MVCC看成行级别锁的一种斗争，它在许多状况下防止了应用锁，同时能够提供更小的开销。依据实现的不同，它能够容许非阻塞式读，在写操作进行时只锁定必要的记录。
MVCC的实现原理
MVCC的是通过保留数据澡某个工夫点的快照来实现的，也就是说，不论事务执行多长的工夫，每个事务看到的数据都是统一的。依据事务的开始工夫不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。InnonDB次要通过为每一行记录增加两个额定的暗藏的值来实现MVCC，这两个值一个记录这行数据何时被创立，另外一个记录这行数据何时过期（或者被删除）。然而InnoDB并不存储这些事件产生时的 理论工夫 ，相同它只存储这些事件产生时的零碎 版本号（version） 。这是一个随着事务的创立而一直增长的数字。每个事务在事务开始时会记录它本人的零碎版本号。每个查问必须去查看每行数据的版本号与事务的版本号是否雷同。
《高性能MySQL》书籍中介绍到：
MVCC只在REPEATABLE READ和READ COMMITTIED两个隔离级别下工作，其余两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不合乎以后事务版本数据行，而SERIALIZABLE串行化隔离级别则会对所有读取的行都加锁。
接下来举个例子阐明在可反复读事务隔离级别下，MVCC机制是如何实现增删改查操作的。
- 查问操作（SELECT）
在查问操作中，InnoDB存储引擎跟依据以下两个条件查问对应的行记录，只有满足对应条件才会被返回：
1️ 只查找不晚于以后事务版本的数据行，也就是说，InnoDB存储引擎只会查找版本号小于或者等于以后事务版本的数据行，这些数据行要么在该事务开始前就存在，要么就是事务自身插入或者更新的行。
2️ 对于数据删除，数据行删除的版本要么还没有被定义，要么大于以后事务的版本号，只有这样能力确保事务读到的行，在事务开始前并没有被删除。
举个例子，存在 事务A 和 事务B 两个事务，事务A中存在两套雷同的SELECT语句，事务B存在一条UPDATE语句，事务A 的第一条查问语句在事务B提交之前执行，第二条查问语句在 事务B 提交之后执行，事务A 如下所示：
-- 事务A操作START TRANSACTION;SELECT * FROM account WHERE id = 1; //在事务B提交之前执行SELECT * FROM account WHERE id = 1; //在事务B提交之后执行COMMIT;事务B：
-- 事务B操作START TRANSACTION;UPDATE account SET balance = balance+100 WHERE id = 1;COMMIT;✔论断：如果没有应用MVCC机制，则事务A中的第一条SELECT语句读取的数据是批改前的数据，而第二条SELECT语句读取的是批改后的数据，两次读取的数据不统一，想想，那不就乱了吗? 如果应用了MVCC机制，无论事务B如何批改数据，事务A的两条查问语句的到的后果始终是统一的。
- 插入操作（SELECT）
在插入操作中，InnoDB会将新插入的每一条行记录的以后零碎版本包保留为行版本号。
比方：向account表插入一条数据，同时MVCC的两个版本号别离为create_version和delete_version，create_version代表创立行的版本号，delete_version代表删除行的版本号，另外还有一个事务ID字段，如上面所示：
INSERT INTO account(id, name, balance) values(1001, 'austin', 100);复制代码对应的版本号信息如下表：
| id | name | balance | transaction_id | create_version | delete_version |
|---|---|---|---|---|---|
| 1001 | austin | 100 | 1 | 1 | 未定义 |
能够看出，当向数据表新增记录时，须要设置保留行的版本号，而删除行的版本号未定义。
- 更新操作（SELECT）
在更新操作中，InnoDB存储引擎会插入一行新记录，并保留以后零碎的版本号为新记录行的版本号，同时保留以后零碎的版本号到原来数据行作为删除标识。比方：将account数据表中id为1001的用户账户月减少100元，对应SQL如下：
UPDATE account SET balance = balance+100 WHERE id = 1001;复制代码执行SQL, 在MVCC机制下的更新操作如下表所示：
| id | name | balance | transaction_id | create_version | delete_version |
|---|---|---|---|---|---|
| 1001 | austin | 100 | 1 | 1 | 2 |
| 1001 | austin | 200 | 2 | 2 | 未定义 |
能够显著看出，执行更新操作时，MVCC机制是先将原来的数据复制一份，将balance字段减少100后，再讲create_version字段的值设置为以后零碎的版本号，而delete_version字段的值未定义。
留神的是：原来的行会被复制到Undo Log中。
- 删除操作（SELECT）
在删除操作中，InnoDB存储引擎会保留删除的每一个行记录以后的零碎版本号，作为删除标识。比方：删除account数据表中id为1001的数据，SQL如下所示：
DELETE FROM account WHERE id = 1001;复制代码对应MVCC机制下的删除操作如下表所示：
| id | name | balance | transaction_id | create_version | delete_version |
|---|---|---|---|---|---|
| 1001 | austin | 200 | 3 | 2 | 3 |
能够看出，当删除数据表数据行时，MVCC机制会将以后零碎的版本号写入删除数据行版本字段delete_version中，以此来示意以后数据行曾经被删除。
六、总结
本文次要讲述了事务的个性、类型和本地事务和分布式事务的区别，通过不同的示例解释并发事务带来的更新失落、脏读、不可反复读、幻读的问题，同时介绍了多版本并发管制MVCC的实现原理。