标签：情况下   glob   阶段   取数   tor   var   where   原子性   根据   

官方手册：https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-transaction-model.html

1.事务特性

事务具有ACID特性：原子性(A,atomicity)、一致性(C,consistency)、隔离性(I,isolation)、持久性(D,durabulity)。

• 原子性：事务内的所有操作要么都执行，要么都不执行。
• 一致性：事务开始和结束前后，数据都满足数据一致性约束，而不是经过事务控制之后数据变得不满足条件或业务规则。
• 隔离性：事务之间不能互影响，它们必须完全的各行其道，互不可见。
• 持久性：事务完成后，该事务内涉及的数据必须持久性的写入磁盘保证其持久性。当然，这是从事务的角度来考虑的的持久性，从操作系统故障或硬件故障来说，这是不一定的。

2.事务分类

• 扁平事务
• 带保存点的扁平事务
• 链事务
• 嵌套事务
• 分布式事务

2.1 扁平事务

即最常见的事务。由begin开始，commit或rollback结束，中间的所有操作要么都回滚要么都提交。扁平事务在生产环境中占绝大多数使用情况。因此每一种数据库产品都支持扁平事务。

扁平事务的缺点在于无法回滚或提交一部分，只能全部回滚或全部提交，所以就有了"带有保存点"的扁平事务。

2.2 带有保存点的扁平事务

通过在事务内部的某个位置使用savepoint，将来可以在事务中回滚到此位置。

MariaDB/MySQL中设置保存点的命令为:

savepoint [savepoint_name]

回滚到指定保存点的命令为：

rollback to savepoint_name

删除一个保存点的命令为：

release savepoint savepoint_name

实际上，扁平事务也是有保存点的，只不过它只有一个隐式的保存点，且自动建立在事务开始的位置，因此扁平事务只能回滚到事务开始处。

2.3 链式事务

链式事务是保存点扁平事务的变种。它在一个事务提交的时候自动隐式的将上下文传给下一个事务，也就是说一个事务的提交和下一个事务的开始是原子性的，下一个事务可以看到上一个事务的处理结果。通俗地说，就是事务的提交和事务的开始是链接式下去的。

这样的事务类型，在提交事务的时候，会释放要提交事务内所有的锁和要提交事务内所有的保存点。因此链式事务只能回滚到当前所在事务的保存点，而不能回滚到已提交的事务中的保存点。

2.4 嵌套事务

嵌套事务由一个顶层事务控制所有的子事务。子事务的提交完成后不会真的提交，而是等到顶层事务提交才真正的提交。

关于嵌套事务的机制，主要有以下3个结论：

• 回滚内部事务的同时会回滚到外部事务的起始点。
• 事务提交时从内向外依次提交。
• 回滚外部事务的同时会回滚所有事务，包括已提交的内部事务。因为只提交内部事务时没有真的提交。

不管怎么样，最好少用嵌套事务。且MariaDB/MySQL不原生态支持嵌套事务(SQL Server支持)。

2.5 分布式事务

将多个服务器上的事务(节点)组合形成一个遵循事务特性(acid)的分布式事务。

例如在工行atm机转账到建行用户。工行atm机所在数据库是一个事务节点A，建行数据库是一个事务节点B，仅靠工行atm机是无法完成转账工作的，因为它控制不了建行的事务。所以它们组成一个分布式事务：

• 1.atm机发出转账口令。
• 2.atm机从工行用户减少N元。
• 3.在建行用户增加N元。
• 4.在atm机上返回转账成功或失败。

上面涉及了两个事务节点，这些事务节点之间的事务必须同时具有acid属性，要么所有的事务都成功，要么所有的事务都失败，不能只成功atm机的事务，而建行的事务失败。

MariaDB/MySQL的分布式事务使用两段式提交协议(2-phase commit,2PC)。最重要的是，MySQL 5.7.7之前，MySQL对分布式事务的支持一直都不完善(第一阶段提交后不会写binlog，导致宕机丢失日志)，这个问题持续时间长达数十年，直到MySQL 5.7.7，才完美支持分布式事务。相关内容可参考网上一篇文章：https://www.linuxidc.com/Linux/2016-02/128053.htm。遗憾的是，MariaDB至今(MariaDB 10.3.6)都没有解决这个问题。

3.事务控制语句

• begin 和 start transaction表示显式开启一个事务。它们之间并没有什么区别，但是在存储过程中，begin会被识别成begin...end的语句块，所以存储过程只能使用start transaction来显式开启一个事务。
• commit 和 commit work用于提交一个事务。
• rollback 和 rollback work用于回滚一个事务。
• savepoint identifier表示在事务中创建一个保存点。一个事务中允许存在多个保存点。
• release savepoint identifier表示删除一个保存点。当要删除的保存点不存在的时候会抛出异常。
• rollback to savepoint表示回滚到指定的保存点，回滚到保存点后，该保存点之后的所有操纵都被回滚。注意，rollback to不会结束事务，只是回到某一个保存点的状态。
• set transaction用来设置事务的隔离级别。可设置的隔离级别有read uncommitted/read committed/repeatable read/serializable。

commit与commit work以及rollback与rollback work作用是一样的。但是他们的作用却和变量completion_type的值有关。

例如将completion_type设置为1，进行测试。

1
2
3
4
5
6
7
8
9
10
11
12
13
mysql> set completion_type=1;
mysql> begin;
mysql> insert into ttt values(1000);
mysql> commit work;
mysql> insert into ttt values(2000);
mysql> rollback;
mysql> select * from ttt where id>=1000;
+------+
| id   |
+------+
| 1000 |
+------+
1 row in set (0.00 sec)

begin开始事务后，插入了值为1000的记录，commit work了一次，然后再插入了值为2000的记录后rollback，查询结果结果中只显示了1000，而没有2000，因为commit work提交后自动又开启了一个事务，使用rollback会回滚该事务。

将completion_type设置为2，进行测试。

1
2
3
4
mysql> set completion_type=2;
mysql> begin;
mysql> insert into ttt select 1000;
mysql> commit;

提交后，再查询或者进行其他操作，结果提示已经和MariaDB/MySQL服务器断开连接了。

1
2
3
mysql> select * from ttt;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...

4.显式事务的次数统计

通过全局状态变量com_commit和com_rollback可以查看当前已经显式提交和显式回滚事务的次数。还可以看到回滚到保存点的次数。

1
2
3
4
5
6
7
8
9
10
11
12
13
mysql> show global status like "%com_commit%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_commit    | 14    |
+---------------+-------+
mysql> show global status like "%com_rollback%";
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Com_rollback              | 24    |
| Com_rollback_to_savepoint | 0     |
+---------------------------+-------+

5.一致性非锁定读(快照查询)

在innodb存储引擎中，存在一种数据查询方式：快照查询。因为查询的是快照数据，所以查询时不申请共享锁。

当进行一致性非锁定读查询的时候，查询操作不会去等待记录上的独占锁释放，而是直接去读取快照数据。快照数据是通过undo段来实现的，因此它基本不会产生开销。显然，通过这种方式，可以极大的提高读并发性。

快照数据其实是行版本数据，一个行记录可能会存在多个行版本，并发时这种读取行版本的方式称为多版本并发控制(MVCC)。在隔离级别为read committed和repeatable read时，采取的查询方式就是一致性非锁定读方式。但是，不同的隔离级别下，读取行版本的方式是不一样的。在后面介绍对应的隔离级别时会作出说明。

下面是在innodb默认的隔离级别是repeatable read下的实验，该隔离级别下，事务总是在开启的时候获取最新的行版本，并一直持有该版本直到事务结束。更多的"一致性非锁定读"见后文说明read committed和repeatable read部分。

当前示例表ttt的记录如下：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

在会话1执行：

1
2
mysql> begin;
mysql> update ttt set id=100 where id=1

在会话2中执行：

1
2
3
4
5
6
7
8
mysql> begin;
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

查询的结果和预期的一样，来自开启事务前最新提交的行版本数据。

回到会话1提交事务：

mysql> commit;

再回到会话2中查询：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

再次去会话1更新该记录：

1
2
3
mysql> begin;
mysql> update ttt set id=1000 where id=100;
mysql> commit;

再回到会话2执行查询：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

这就是repeatable read隔离级别下的一致性非锁定读的特性。

当然，MySQL也支持一致性锁定读的方式。

6.一致性锁定读

在隔离级别为read committed和repeatable read时，采取的查询方式就是一致性非锁定读方式。但是在某些情况下，需要人为的对读操作进行加锁。MySQL中对这种方式的支持是通过在select语句后加上lock in share mode或者for update。

• select ... from ... where ... lock in share mode;
• select ...from ... where ... for update;

使用lock in share mode会对select语句要查询的记录加上一个共享锁(S)，使用for update语句会对select语句要查询的记录加上独占锁(X)。

另外，对于一致性非锁定读操作，即使要查询的记录已经被for update加上了独占锁，也一样可以读取，就和纯粹的update加的锁一样，只不过此时读取的是快照数据而已。

7.事务隔离级别

SQL标准定义了4中隔离级别：read uncommitted、read committed、repeatable read、serializable。

MariaDB/MySQL也支持这4种隔离级别。但是要注意的是，MySQL中实现的隔离级别和SQL Server实现的隔离级别在同级别上有些差别。在后面有必要说明地方会给出它们的差异之处。

MariaDB/MySQL中默认的隔离级别是repeatable read，SQL Server和oracle的默认隔离级别都是read committed。

事务特性(ACID)中的隔离性(I,isolation)就是隔离级别，它通过锁来实现。也就是说，设置不同的隔离级别，其本质只是控制不同的锁行为。例如操作是否申请锁，什么时候申请锁，申请的锁是立刻释放还是持久持有直到事务结束才释放等。

7.1 设置和查看事务隔离级别

隔离级别是基于会话设置的，当然也可以基于全局进行设置，设置为全局时，不会影响当前会话的级别。设置的方法是：

1
2
3
set [global | session] transaction isolation level {type}
type:
    read uncommitted | read committed | repeatable read | serializable

或者直接修改变量值也可以：

1
2
set @@global.tx_isolation = ‘read-uncommitted‘ | ‘read-committed‘ | ‘repeatable-read‘ | ‘serializable‘
set @@session.tx_isolation = ‘read-uncommitted‘ | ‘read-committed‘ | ‘repeatable-read‘ | ‘serializable‘

查看当前会话的隔离级别方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
mysql> select @@tx_isolation;
mysql> select @@global.tx_isolation;
mysql> select @@tx_isolation;select @@global.tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
+-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ       |
+-----------------------+

注意，事务隔离级别的设置只需在需要的一端设置，不用在两边会话都设置。例如想要让会话2的查询加锁，则只需在会话2上设置serializable，在会话1设置的serializable对会话2是没有影响的，这和SQL Server中一样。但是，MariaDB/MySQL除了serializable隔离级别，其他的隔离级别都默认会读取旧的行版本，所以查询永远不会造成阻塞。而SQL Server中只有基于快照的两种隔离级别才会读取行版本，所以在4种标准的隔离级别下，如果查询加的S锁被阻塞，查询会进入锁等待。

在MariaDB/MySQL中不会出现更新丢失的问题，因为独占锁一直持有直到事务结束。当1个会话开启事务A修改某记录，另一个会话也开启事务B修改该记录，该修改被阻塞，当事务A提交后，事务B中的更新立刻执行成功，但是执行成功后查询却发现数据并没有随着事务B的想法而改变，因为这时候事务B更新的那条记录已经不是原来的记录了。但是事务A回滚的话，事务B是可以正常更新的，但这没有丢失更新。

7.2 read uncommitted

该级别称为未提交读，即允许读取未提交的数据。

在该隔离级别下，读数据的时候不会申请读锁，所以也不会出现查询被阻塞的情况。

在会话1执行：

1
2
3
4
5
create table ttt(id int);
insert into ttt select 1;
insert into ttt select 2;
begin;
update ttt set id=10 where id=1;

如果会话1的隔离级别不是默认的，那么在执行update的过程中，可能会遇到以下错误：

ERROR 1665 (HY000): Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

这是read committed和read uncommitted两个隔离级别只允许row格式的二进制日志记录格式。而当前的二进制日志格式记录方式为statement时就会报错。要解决这个问题，只要将格式设置为row或者mixed即可。

set @@session.binlog_format=row;

在会话2执行：

1
2
3
4
5
6
7
8
set transaction isolation level read uncommitted;
select * from ttt;
+------+
| id   |
+------+
|   10 |
|    2 |
+------+

发现查询的结果是update后的数据，但是这个数据是会话1未提交的数据。这是脏读的问题，即读取了未提交的脏数据。

如果此时会话1进行了回滚操作，那么会话2上查询的结果又变成了id=1。

在会话1上执行：

rollback;

在会话2上查询：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

这是读不一致问题。即同一个会话中对同一条记录的读取结果不一致。

read uncommitted一般不会在生产环境中使用，因为问题太多，会导致脏读、丢失的更新、幻影读、读不一致的问题。但由于不申请读锁，从理论上来说，它的并发性是最佳的。所以在某些特殊情况下还是会考虑使用该级别。

要解决脏读、读不一致问题，只需在查询记录的时候加上共享锁即可。这样在其他事务更新数据的时候就无法查询到更新前的记录。这就是read commmitted隔离级别。

7.3 read committed

对于熟悉SQL Server的人来说，在说明这个隔离级别之前，必须先给个提醒：MariaDB/MySQL中的提交读和SQL Server中的提交读完全不一样，MariaDB/MySQL中该级别基本类似于SQL Server中基于快照的提交读。

在SQL Server中，提交读的查询会申请共享锁，并且在查询结束的一刻立即释放共享锁，如果要查询的记录正好被独占锁锁住，则会进入锁等待，而没有被独占锁锁住的记录则可以正常查询。SQL Server中基于快照的提交读实现的是语句级的事务一致性，每执行一次操作事务序列号加1，并且每次查询的结果都是最新提交的行版本快照。

也就是说，MariaDB/MySQL中read committed级别总是会读取最新提交的行版本。这在MySQL的innodb中算是一个术语:"一致性非锁定读"，即只读取快照数据，不加共享锁。这在前文已经说明过。

MariaDB/MySQL中的read committed隔离级别下，除非是要检查外键约束或者唯一性约束需要用到gap lock算法，其他时候都不会用到。也就是说在此隔离级别下，一般来说只会对行进行锁定，不会锁定范围，所以会导致幻影读问题。

这里要演示的就是在该级别下，会不断的读取最新提交的行版本数据。

当前示例表ttt的记录如下：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

在会话1中执行：

begin;update ttt set id=100 where id=1;

在会话2中执行：

1
2
3
set @@session.tx_isolation=‘read-committed‘;
begin;
select * from ttt;

会话2中查询得到的结果为id=1，因为查询的是最新提交的快照数据，而最新提交的快照数据就是id=1。

1
2
3
4
5
6
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

现在将会话1中的事务提交。

在会话1中执行：

commit;

在会话2中查询记录：

1
2
3
4
5
6
7
select * from ttt;
+------+
| id   |
+------+
|  100 |
|    2 |
+------+

结果为id=100，因为这个值是最新提交的。

再次在会话1中修改该值并提交事务。

在会话1中执行：

begin;update ttt set id=1000 where id=100;commit;

在会话2中执行：

1
2
3
4
5
6
7
select * from ttt;
+------+
| id   |
+------+
| 1000 |
|    2 |
+------+

发现结果变成了1000，因为1000是最新提交的数据。

read committed隔离级别的行版本读取特性，在和repeatable read隔离级别比较后就很容易理解。

7.4 repeatable read

同样是和上面一样的废话，对于熟悉SQL Server的人来说，在说明这个隔离级别之前，必须先给个提醒：MariaDB/MySQL中的重复读和SQL Server中的重复读完全不一样，MariaDB/MySQL中该级别基本类似于SQL Server中快照隔离级别。

在SQL Server中，重复读的查询会申请共享锁，并且在查询结束的一刻不释放共享锁，而是持有到事务结束。所以会造成比较严重的读写并发问题。SQL Server中快照隔离级别实现的是事务级的事务一致性，每次事务开启的时候获取最新的已提交行版本，只要事务不结束，读取的记录将一直是该行版本中的数据，不管其他事务是否已经提交过对应的数据了。但是SQL Server中的快照隔离会有更新冲突：当检测到两边都想要更新同一记录时，会检测出更新冲突，这样会提前结束事务(进行的是回滚操作)而不用再显式地commit或者rollback。

也就是说，MariaDB/MySQL中repeatable read级别总是会在事务开启的时候读取最新提交的行版本，并将该行版本一直持有到事务结束。但是MySQL中的repeatable read级别下不会像SQL Server一样出现更新冲突的问题。

前文说过read committed隔离级别下，读取数据时总是会去获取最新已提交的行版本。这是这两个隔离级别在"一致性非锁定读"上的区别。

另外，MariaDB/MySQL中的repeatable read的加锁方式是next-key lock算法，它会进行范围锁定。这就避免了幻影读的问题(官方手册上说无法避免)。在标准SQL中定义的隔离级别中，需要达到serializable级别才能避免幻影读问题，也就是说MariaDB/MySQL中的repeatable read隔离级别已经达到了其他数据库产品(如SQL Server)的serializable级别，而且SQL Server中的serializable加范围锁时，在有索引的时候式锁范围比较不可控(你不知道范围锁锁住哪些具体的范围)，而在MySQL中是可以判断锁定范围的(见innodb锁算法)。

这里要演示的就是在该级别下，读取的行版本数据是不随提交而改变的。

当前示例表ttt的记录如下：

1
2
3
4
5
6
7
mysql> select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

在会话1执行：

begin;update ttt set id=100 where id=1

在会话2中执行：

1
2
3
4
5
6
7
8
set @@session.tx_isolation=‘repeatable-read‘;
begin;select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

查询的结果和预期的一样，来自开启事务前最新提交的行版本数据。

回到会话1提交事务：

commit;

再回到会话2中查询：

1
2
3
4
5
6
7
select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

再次去会话1更新该记录：

begin;update ttt set id=1000 where id=100;commit;

再回到会话2执行查询：

1
2
3
4
5
6
7
select * from ttt;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+

发现结果根本就不会改变，因为会话2开启事务时获取的行版本的id=1，所以之后读取的一直都是id=1所在的行版本。

7.5 serializable

在SQL Server中，serializable隔离级别会将查询申请的共享锁持有到事务结束，且申请的锁是范围锁，范围锁的情况根据表有无索引而不同：无索引时锁定整个表，有索引时锁定某些范围，至于锁定哪些具体的范围我发现是不可控的(至少我无法推测和计算)。这样就避免了幻影读的问题。

这种问题在MariaDB/MySQL中的repeatable read级别就已经实现了，MariaDB/MySQL中的next-key锁算法在加范围锁时也分有无索引：无索引时加锁整个表(实际上不是表而是无穷大区间的行记录)，有索引时加锁部分可控的范围。

MariaDB/MySQL中的serializable其实类似于repeatable read，只不过所有的select语句会自动在后面加上lock in share mode。也就是说会对所有的读进行加锁，而不是读取行版本的快照数据，也就不再支持"一致性非锁定读"。这样就实现了串行化的事务隔离：每一个事务必须等待前一个事务(哪怕是只有查询的事务)结束后才能进行哪怕只是查询的操作。

这个隔离级别对并发性来说，显然是有点太严格了。

https://www.cnblogs.com/f-ck-need-u/p/8997814.html

MySQL/MariaDB中的事务和事务隔离级别

标签：情况下   glob   阶段   取数   tor   var   where   原子性   根据   

原文地址：https://www.cnblogs.com/softidea/p/12001239.html