全面了解MySQL中的事务
一个项目，一直在做订单班已用于最近。我们的数据库选择MySQL InnoDB存储引擎，，和InnoDB有良好支持的交易。在这篇文章中，我们将一起拿起相关知识。你为什么要做生意
它在很多情况下被广泛使用，如订单系统、银行系统等。如果有以下情况：用户和B用户是银行的储户。现在A要把500元转到B：
1。支票账户余额500元；
2。一个账户扣除了500元；
三.b账户增加500元。
正常的进程下降了，账户是500，B账户加了500。如果账户扣了钱，系统就没有问题了损失了500英镑，B没有收到本来应该属于他的500英镑。在上述情况下，先决条件是：扣钱和B加钱，同时或同时，这是交易的需要。
生意是什么
与其给出一个事务的定义，不如说一个事务的特性。众所周知，事务必须满足四个特性。
1。一个原子（原子性）。一个事务的执行是一个不可分割的最小单元。在交易操作是成功执行，要么全部失败回滚，而不是它的一部分可以执行。
2。c（一致性）一致性。事务的执行不应破坏数据库的完整性约束。如果系统在上述示例的第二次操作之后崩溃，那么A和B的总金额不会改变。
三.我（孤立）孤立。一般来说，事务之间的行为不应该相互影响。实际上，交互作用的程度受孤立程度的影响。
4。在提交事务后，提交的事务需要保存到磁盘。即使系统崩溃，提交的数据也不应该丢失。
事务的四个隔离级别
如前一篇文章所提到的，隔离的影响会影响事务的隔离。那么事务的隔离级别是什么事务的隔离级别被认为是事务的自私程度，它定义事务之间的可见性：
1.read未遂（未提交读）。在Ru的隔离级别，通过交易数据的修改，即使是不提交的，也是交易B可见，称为脏读。这是一个低的隔离级别，可以在实际使用中造成很多问题，因此一般不常用。
2.read提交（提交读）。没有在RC隔离级别脏读事务修改数据的问题。提交后，会看到交易为例，当交易B打开，读取数据1，那么交易一打开，变化的数据2、提交、B读取数据，读取最新数据2。在钢筋混凝土的隔离级别，会有不可重复读取的问题。该隔离级别是许多数据库的默认隔离级别。
3.repeatable读（可以反复阅读），RR隔离级别，没有什么问题是不能反复阅读。交易的变化数据，并提交后，它不是交易前A例如打开交易可见，当事务B打开，读取数据1，然后交易一打开，变化的数据2、提交、B读取数据了，还是只能读1，RR隔离级别，会有一种虚幻的阅读问题。魔法阅读中的意义就是当一个事务读取的值的范围，在这个范围内的另一个事务插入一个新的记录。交易前阅读此范围的值，它将读取新插入的数据。MySQL的默认隔离级别是RR，但MySQL InnoDB引擎间隙锁成功地解决了幻读的问题。
4.serializable（序列化）。Serializable是最高的隔离级别，该隔离级别要求都是顺序执行的。在这种隔离级别上，读取的每一行数据都被锁定，导致大量的锁请求，性能是最差的。
为了帮助理解四个隔离级别，下面是一个例子。如图1所示，事务A和事务B相继被打开，并且数据1被多次更新。当四个人在不同的时间打开事务时，数据1的值是多少
图1
第一点的人都可以看的数据1-20.the修饰也是当前事务可见由于未提交读隔离级别。二人可能读到1, 10和20，而他只会读，已经被其他的东西所提交的数据，第三的人阅读是在为自己事务时间点确定的数据。当交易打开，什么是阅读，然后是什么之前提交事务读取的值。第四人，仅开放之间的结束和B开始，可以读取数据，且数据无法交易和交易B执行期间阅读。自从第四人阅读需要锁定的数据，事务的执行过程中，B，数据锁将被占用，导致第四人等待锁。
图2列出了不同级别的隔离所面临的问题。
图2
很显然，隔离级别越高，越大，它所带来的资源消耗（锁），所以其并发性能较低。要精确，有无并发SERIALIZABLE隔离级别。
图3
交易在MySQL
一个事务的执行是基于数据库的存储引擎，不同的存储引擎有不同程度的交易支持的存储引擎，MySQL InnoDB支持事务，NDB.InnoDB是一个默认的存储引擎，MySQL的默认隔离级别是RR，RR和隔离级别，进一步，通过多版本并发（MVCC的多版本控制，并发控制）来解决不可重复读，再加上一个间隙锁（即并发控制）来解决虚拟问题读。所以InnoDB RR隔离级别上实现了系列化水平的影响，并保持并发性能好。
事务的隔离是通过锁来实现的，而原子性，一致性，和交易的持久性是通过事务日志来实现的。当涉及到事务日志，你不得不说重做和撤消。
1.redo日志
在InnoDB存储引擎，事务日志重做（redo）实现了日志和日志缓冲区（innodb log buffer）的InnoDB存储引擎。当交易打开，交易中的交易将首先被写入存储引擎日志缓冲区。在提交事务之前，需要将这些缓冲日志提前刷新到磁盘持久性。这是先写日志，DBA常常谈起。当事务提交时，那是在缓冲池中映射数据文件会慢慢刷新到磁盘。如果数据库崩溃或停机，所以当系统重新启动时恢复，可以根据日志重做日志，将数据库恢复到一个状态在崩溃前，未完成的事务可以提交或回滚，以恢复策略。
在系统启动的时候，一个连续的存储空间分配给了日志，日志是按顺序添加，和性能是由顺序IO提高。所有的交易份额的重做日志的存储空间，其重做日志顺序记录在序列根据语句的执行顺序。一个简单的例子是以下：
记录1：
记录2：
记录3：
记录4：
记录5：
2.undo日志
撤消日志主要是事务的回滚服务，在事务执行过程中，除了记录重做日志外，还记录了一定数量的撤销日志，撤消日志记录每个操作之前的数据状态。如果事务需要在事务期间回滚，则回滚操作可以在撤消日志的基础上执行。单个事务的回滚只会回滚当前事务所做的操作，并且不影响其他事务所做的操作。
以下是撤销/重做事务的简化
假设有2个值，A和B，值为1, 2。
1。开始交易；
2。记录a = 1以撤消日志；
三.更新a = 3；
4。将日志记录为重做日志3；
5。记录b = 2以撤消日志；
6。更新B = 4；
7。记录B＝4重做日志；
8。将重做日志刷新到磁盘
9。犯罪
1-8任何步骤的系统停机，未提交的事务，事务将不会使磁盘上的数据的任何影响。如果在8-9的停机，恢复后可以选择回滚，你也可以选择完成事务的提交，因为重做日志一直持续。如果9系统停机后，改变内存映射回到盘面刷数据，然后恢复后，根据重做日志数据到磁盘刷。
所以，重做日志实际上保证持久性和一致性的交易，并撤消日志保证事务的原子性。
分布式事务
有许多方法来实现分布式事务，不仅可以使用InnoDB的事务支持，但也使用消息队列来实现分布式事务的最终一致性。我们在这里讨论的是分布式事务的InnoDB的支持。
例如，MySQL的分布式事务模型。该模型分为三个块：AP、RM、事务管理器（TM）。
应用程序定义事务的边界，指定需要做的工作；
资源管理器提供了访问事务的方法，通常数据库是资源管理器；
事务管理器参与全局事务中的各种事务。
分布式事务中使用的两款（2pc）的方式。在第一阶段，所有的交易节点准备告诉事务经理准备。第二阶段交易经理告诉每个节点是否提交或回滚。如果一个节点发生故障，整个回滚的全球节点需要事务的原子性。
总结
您什么时候需要使用这笔交易我认为交易的支持的话，只要业务需要满足酸的场景。特别是在订单系统，银行系统，交易是必不可少的。本文主要介绍了交易的特点，通过MySQL InnoDB的事务支持，对事务有关的知识是远远以上的文章。这篇文章只不过是块砖头而已。