mysql-事务

http://baijiahao.baidu.com/s?id=1581064626251873652&wfr=spider&for=pc

MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。

事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。

事务用来管理 insert,update,delete 语句

一般来说，事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关。MySQL的存储引擎有InnoDB，MyISAM，Memory等，它们对事务的支持如下：

一、为什么要使用事务

事务是一条或多条数据库操作的集合，在事务中的操作，要么都执行修改，要么都不执行。银行转账是经典的解释事务的例子，如：用户A给用户B转账5000元主要步骤可以概括为以下几步：

检测A账户余额 > 5000元

A账户余额减去 5000元

B账户余额增加 5000元

这几步要么都成功，要么一个都不成功，否则都会导致数据不一致（5000元不翼而飞）。这就可以用到事务来保证，如果是不同银行之间的转账还需要用到分布式事务。

二、事务的性质

严格上来说，事务必须同时满足四个特性，即通常所说的ACID属性：

A（atomicity）原子性。一个事务的执行被视为一个不可分割的最小单元。事务里面的操作，要么全部成功执行，要么全部失败回滚，不可以只执行其中的一部分。

C（consistency）一致性。一个事务的执行不应该破坏数据库的完整性约束。如果上述例子中第2个操作执行后系统崩溃，保证A和B的金钱总计是不会变的。

I（isolation）隔离性。事务之间相互独立，互不干挠。

D（durability）持久性。事务提交之后，需要将提交的事务持久化到磁盘。即使系统崩溃，提交的数据也不应该丢失。

三、事务的隔离级别

事务的隔离级别主要分为以下几种：

READ UNCOMMITTED（未提交读），事务中的修改，即使没有提交，在其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。

READ COMMITTED（提交读），一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读，因为两次执行相同的查询，可能会得到不一样的结果。因为在这两次读之间可能有其他事务更改这个数据，每次读到的数据都是已经提交的。

REPEATABLE READ（可重复读），解决了脏读，也保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另外一个幻读的问题，指的是当某个事务在读取某个范围内的记录时，另外一个事务也在该范围内插入了新的记录，当之前的事务再次读取该范围内的记录时，会产生幻行。

SERIALIZABLE（可串行化），它通过强制事务串行执行，避免了前面说的幻读的问题，但由于读取的每行数据都加锁，会导致大量的锁征用问题，因此性能也最差。

四、原子性、一致性和持久性实现原理

事务的隔离性是通过锁实现的，而事务的原子性、一致性、持久性则是通过事务日志实现的，说到日志就不得不说 redo 和 undo。

不管是 redo 还是 undo 文件都会有一个缓存我们称之为 redo_buf 和 undo_buf，同样，数据库文件也会有缓存称之为 data_buf。

1. undo 日志文件

undo记录了数据在事务开始之前的值，当事务执行失败或者ROLLBACK时可以通过 undo 记录的值来恢复数据。例如AA和BB的初始值分别为3，5。

A 事务开始

B 记录AA=3到undo_buf

C 修改AA=1

D 记录BB=5到undo_buf

E 修改BB=7

F 将undo_buf写到undo(磁盘)

G 将data_buf写到datafile(磁盘)

H 事务提交

通过undo可以保证原子性、一致性和持久性。如果事务在F之前崩溃由于数据还没写入磁盘，所以数据不会被破坏。如果事务在G之前崩溃或者回滚则可以根据undo恢复到初始状态。数据在任务提交之前写到磁盘保证了持久性。但是单纯使用undo保证原子性和持久性需要在事务提交之前将数据写到磁盘，浪费大量I/O。

2. redo/undo 日志文件

引入redo日志记录数据修改后的值，可以避免数据在事务提交之前必须写入到磁盘的需求，减少I/O。

C 修改AA=1 记录redo_buf

E 修改BB=7 记录redo_buf

F 将redo_buf写到redo（磁盘）

G 事务提交

通过undo保证事务的原子性，redo保证持久性。F之前崩溃由于所有数据都在内存，恢复后重新从磁盘载入之前的数据，数据没有被破坏。FG之间的崩溃可以使用redo来恢复。G之前的回滚都可以使用undo来完成。

五、事务操作命令

BEGIN 或 START TRANSACTION：显式地开启一个事务

COMMIT：也可以使用COMMIT WORK，不过二者是等价的。COMMIT会提交事务，并使已对数据库进行的所有修改成为永久性的

ROLLBACK：也可以使用ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改

SAVEPOINT identifier：SAVEPOINT允许在事务中创建一个保存点，一个事务中可以有多个SAVEPOINT

RELEASE SAVEPOINT identifier：删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常

ROLLBACK TO identifier：把事务回滚到标记点

SET TRANSACTION：用来设置事务的隔离级别。InnoDB存储引擎提供事务的隔离级别有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE

六、测试

这里使用 BEGIN，ROLLBACK，COMMIT 命令来实现。具体测试流程见图：

可见事务的使用是很简单的，当然这只是最基本的用法，有兴趣的同学请自行深入了解。一般来说只要业务中需要满足ACID的场景，都需要事务的支持。尤其在订单系统、银行系统中，事务更是不可或缺。

--END

https://www.jianshu.com/p/4e3edbedb9a8

好久没碰数据库了，只是想起自己当时在搞数据库的时候在事务隔离级别这块老是卡，似懂非懂的。现在想把这块整理出来，尽量用最简洁的语言描述出来，供新人参考。

首先创建一个表account。创建表的过程略过（由于InnoDB存储引擎支持事务，所以将表的存储引擎设置为InnoDB）。表的结构如下：

表结构

然后往表中插入两条数据，插入后结果如下：

数据

为了说明问题，我们打开两个控制台分别进行登录来模拟两个用户（暂且成为用户A和用户B吧），并设置当前MySQL会话的事务隔离级别。

一. read uncommitted（读取未提交数据）

具体用户A的操作如下：

setsession transaction isolation levelreaduncommitted；start transaction;select * from account;

结果如下：

数据

用户B的操作如下：

setsession transaction isolation levelreaduncommitted；start transaction;update accountsetaccount=account+200whereid = 1;

随后我们在A用户中查询数据，结果如下：

uncommittedA数据

结论一：

我们将事务隔离级别设置为read uncommitted，即便是事务没有commit，但是我们仍然能读到未提交的数据，这是所有隔离级别中最低的一种。

那么这么做有什么问题吗？

那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据，这还是比较麻烦的，我们叫脏读。我不知道这个名字是怎么起的，为了增强大家的印象，可以这么想，这个事务好轻浮啊，饥渴到连别人没提交的东西都等不及，真脏，呸！

实际上我们的数据改变了吗？

答案是否定的，因为只有事务commit后才会更新到数据库。

二. read committed（可以读取其他事务提交的数据）---大多数数据库默认的隔离级别

同样的办法，我们将用户B所在的会话当前事务隔离级别设置为read commited。

在用户A所在的会话中我们执行下面操作：

update accountsetaccount=account-200whereid=1;

read committed

我们将id=1的用户account减200。然后查询，发现id=1的用户account变为800。

在B用户所在的会话中查询：

select *fromaccount；

结果如下：

read committedB

我们会发现数据并没有变，还是1000。

接着在会话A中我们将事务提交：

commit;

在会话B中查询结果如下：

read committedB1

结论二：

当我们将当前会话的隔离级别设置为read committed的时候，当前会话只能读取到其他事务提交的数据，未提交的数据读不到。

那么这么做有什么问题吗？

那就是我们在会话B同一个事务中，读取到两次不同的结果。这就造成了不可重复读，就是两次读取的结果不同。这种现象叫不可重复读。

三. repeatable read（可重读）---MySQL默认的隔离级别

现在有个需求，就是老板说在同一个事务中查询结果必须保持一致，如果你是数据库，你会怎么做？数据库是这么做的。

在会话B中我们当前事务隔离级别为repeatable read。具体操作如下：

setsession transaction isolation level repeatableread;start transaction;

接着在会话B中查询数据：

repeatablereadB1

我们在A用户所在会话中为表account添加一条数据：

insert intoaccount(id,account)value(3,1000);commit;

然后我们查询看数据插入是否成功：

repeatable readA

回到B用户所在的会话，我们查询结果：

repeatablereadB2

用户B在他所在的会话中想插入一条新数据id=3，value=1000。来我们操作下：

readpeatablereadB3

什么？竟然插不进去，说我数据重复？

用户B当然不服啊，因为查询到数据只有两条啊，为什么插入id=3说我数据重复了呢？

我再看一遍，莫非我眼花了？

repeatablereadB2

试想一下，在实际中用户A和用户B肯定是相互隔离的，彼此不知道操作什么。用户B碰到这种现象，肯定会炸毛的啊，明明不存在的数据，插入却说主键id=3数据重复了。

结论三：

当我们将当前会话的隔离级别设置为repeatable read的时候，当前会话可以重复读，就是每次读取的结果集都相同，而不管其他事务有没有提交。

有什么问题吗？

管他呢，老板的要求满足了。要一个事务中读取的数据一致（可重复读）。我只能这么做啊，打肿脸装胖子。数据已经发生改变，但是我还是要保持一致。但是，出现了用户B面对的问题，这种现象叫幻读（记得当时就在这个地方纠结好久，到底什么是幻读啊）。

四. serializable（串行化）

同样，我们将用户B所在的会话的事务隔离级别设置为serializable并开启事务。

setsession transaction isolation level serializable;start transaction;

在用户B所在的会话中我们执行下面操作：

select *fromaccount;

结果如下：

serializableA

那我们这个时候在用户A所在的会话中写数据呢？

readcommittedA1

我们发现用户A所在的会话陷入等待，如果超时（这个时间可以进行配置），会出现Lock wait time out提示：

readcommittedA2

如果在等待期间我们用户B所在的会话事务提交，那么用户A所在的事务的写操作将提示操作成功。

结论四：

当我们将当前会话的隔离级别设置为serializable的时候，其他会话对该表的写操作将被挂起。可以看到，这是隔离级别中最严格的，但是这样做势必对性能造成影响。所以在实际的选用上，我们要根据当前具体的情况选用合适的。

作者：伞U

链接：https://www.jianshu.com/p/4e3edbedb9a8

來源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

四种隔离级别

Read Uncommitted（读取未提交内容）

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重读）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：