【JDBC第6章】数据库事务

6.1 数据库事务介绍

事务：一组逻辑操作单元,使数据从一种状态变换到另一种状态。
事务处理（事务操作）：保证所有事务都作为一个工作单元来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都被提交(commit)，那么这些修改就永久地保存下来；要么数据库管理系统将放弃所作的所有修改，整个事务回滚(rollback)到最初状态。
为确保数据库中数据的一致性，数据的操纵应当是离散的成组的逻辑单元：当它全部完成时，数据的一致性可以保持，而当这个单元中的一部分操作失败，整个事务应全部视为错误，所有从起始点以后的操作应全部回退到开始状态。

6.2 JDBC事务处理

数据一旦提交，就不可回滚。
数据什么时候意味着提交？
- 当一个连接对象被创建时，默认情况下是自动提交事务：每次执行一个 SQL 语句时，如果执行成功，就会向数据库自动提交，而不能回滚。
- 关闭数据库连接，数据就会自动的提交。如果多个操作，每个操作使用的是自己单独的连接，则无法保证事务。即同一个事务的多个操作必须在同一个连接下。
JDBC程序中为了让多个 SQL 语句作为一个事务执行：
- 调用 Connection 对象的 setAutoCommit(false); 以取消自动提交事务
- 在所有的 SQL 语句都成功执行后，调用 commit(); 方法提交事务
- 在出现异常时，调用 rollback(); 方法回滚事务
若此时 Connection 没有被关闭，还可能被重复使用，则需要恢复其自动提交状态 setAutoCommit(true)。尤其是在使用数据库连接池技术时，执行close()方法前，建议恢复自动提交状态。

【案例：用户AA向用户BB转账100】

public void testJDBCTransaction() {
    Connection conn = null;
    try {
        // 1.获取数据库连接
        conn = JDBCUtils.getConnection();
        // 2.开启事务
        conn.setAutoCommit(false);
        // 3.进行数据库操作
        String sql1 = "update user_table set balance = balance - 100 where user = ?";
        update(conn, sql1, "AA");

        // 模拟网络异常
        //System.out.println(10 / 0);

        String sql2 = "update user_table set balance = balance + 100 where user = ?";
        update(conn, sql2, "BB");
        // 4.若没有异常，则提交事务
        conn.commit();
    } catch (Exception e) {
        e.printStackTrace();
        // 5.若有异常，则回滚事务
        try {
            conn.rollback();
        } catch (SQLException e1) {
            e1.printStackTrace();
        }
    } finally {
        try {
            //6.恢复每次DML操作的自动提交功能
            conn.setAutoCommit(true);
        } catch (SQLException e) {
            e.printStackTrace();
        }
        //7.关闭连接
        JDBCUtils.closeResource(conn, null, null); 
    }  
}

默认情况下，关闭数据库连接，数据就会自动的提交。如果多个操作，每个操作使用的是自己单独的连接，则无法保证事务。即同一个事务的多个操作必须在同一个连接下。

考虑上事务，所以使用同一个连接，将连接作为参数传入，执行完了也不要关闭连接，直到我们外面调用函数时全部事务功能已经结束（即转账，我减少、你增加），再去关闭连接，提交数据。

原先不考虑事务时的步骤：

获取连接
我减少
关闭连接（提交数据）
获取连接
你增加
关闭连接（提交数据）

考虑事务时的步骤：

获取连接
我减少
你增加
关闭连接（提交数据）

其中，对数据库操作的方法为：

//使用事务以后的通用的增删改操作（version 2.0）
public void update(Connection conn ,String sql, Object... args) {
    PreparedStatement ps = null;
    try {
        // 1.获取PreparedStatement的实例 (或：预编译sql语句)
        ps = conn.prepareStatement(sql);
        // 2.填充占位符
        for (int i = 0; i < args.length; i++) {
            ps.setObject(i + 1, args[i]);
        }
        // 3.执行sql语句
        ps.execute();
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        // 4.关闭资源
        JDBCUtils.closeResource(null, ps);

    }
}

6.3 事务的ACID属性

原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

就是把事物分割成像原子一样，表示我们事物需要细微的去控制。比如我给你转钱，里面有我扣钱，你到账。总不能我扣了钱，你没到账这种情况吧。所以就是指转账这个事物，里面的所有环节哪怕一个出错，都需要事物回滚，就是一切回到之前那样。
一致性（Consistency）
事务必须使数据库从一个一致性状态变换到另外一个一致性状态。

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
还是转账来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
隔离性（Isolation）
事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
关于事务的隔离性数据库提供了4种隔离级别，稍后会介绍到。
持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

6.3.1 数据库的并发问题

对于同时运行的多个事务, 当这些事务访问数据库中相同的数据时, 如果没有采取必要的隔离机制, 就会导致各种并发问题:
- 脏读: 对于两个事务 T1, T2, T1 读取了已经被 T2 更新但还没有被提交的字段。之后, 若 T2 回滚, T1读取的内容就是临时且无效的。
  
  没有被提交的数据别人随时有可能回滚，所以是临时且无效的。
  数据被未被提交的数据污染了，脏了。
- 不可重复读: 对于两个事务T1, T2, T1 读取了一个字段, 然后 T2 更新了该字段。之后, T1再次读取同一个字段, 值就不同了。
  
  不可重复地进行读取，因为读取前后不一。
- 幻读: 对于两个事务T1, T2, T1 从一个表中读取了一个字段, 然后 T2 在该表中插入了一些新的行。之后, 如果 T1 再次读取同一个表, 就会多出几行。
  
  就像出现了幻觉，多了几个数据。
数据库事务的隔离性: 数据库系统必须具有隔离并发运行各个事务的能力, 使它们不会相互影响, 避免各种并发问题。
一个事务与其他事务隔离的程度称为隔离级别。数据库规定了多种事务隔离级别, 不同隔离级别对应不同的干扰程度, 隔离级别越高, 数据一致性就越好, 但并发性越弱。

6.3.2 事务的四种隔离级别

数据库提供的4种事务隔离级别：
Oracle 支持的 2 种事务隔离级别：READ COMMITED, SERIALIZABLE。 Oracle 默认的事务隔离级别为: READ COMMITED 。
Mysql 支持 4 种事务隔离级别。Mysql 默认的事务隔离级别为: REPEATABLE READ。

6.3.3 在MySql中设置隔离级别

每启动一个 mysql 程序, 就会获得一个单独的数据库连接. 每个数据库连接都有一个全局变量 @@tx_isolation, 表示当前的事务隔离级别。
查看当前的隔离级别:
```
SELECT @@tx_isolation;
```

设置当前 mySQL 连接的隔离级别:

set  transaction isolation level read committed;

设置数据库系统的全局的隔离级别:

set global transaction isolation level read committed;

补充操作：

创建mysql数据库用户：
```
create user tom identified by 'abc123';
```

授予权限

#授予通过网络方式登录的tom用户，对所有库所有表的全部权限，密码设为abc123.
grant all privileges on *.* to tom@'%'  identified by 'abc123'; 

 #给tom用户使用本地命令行方式，授予atguigudb这个库下的所有表的插删改查的权限。
grant select,insert,delete,update on atguigudb.* to tom@localhost identified by 'abc123';

数据库并发性问题与解决方式

数据库并发性问题

脏读：（读取了未提交的新事物，然后被回滚了）

事务A读取了事务B中尚未提交的数据。如果事务B回滚，则A读取使用了错误的数据。

比如我给你转了100万，但是我还没有提交，此时你查询自己账户，多了100万，很开心。然后我发现转错人了，回滚了事物。然后你100万就没了。在过程中你查到了没有提交事物的数据（多出的100万），这就是脏读。

解决：如果一个事物在读的时候，禁止读取未提交的事物。是不是就解决了。

不可重复读：（读取了提交的新事物，指更新操作）

不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。

不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。

在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如同一个事物前后两次查询同一个数据，期望两次读的内容是一样的，但是因为读的过程中，因为令一个数据写了该数据，导致不可重复读。

解决：如果一个事物在读的时候，禁止任何事物写。是不是就解决了。

幻读：（也是读取了提交的新事物，指增删操作）

在事务A多次读取构成中，事务B对数据进行了新增操作，导致事务A多次读取的数据不一致。幻读和不可重复读的区别在于，不可重复是针对记录的update操作，只要在记录上加写锁，就可避免；幻读是对记录的insert操作，

要禁止幻读必须加上全局的写锁(比如在表上加写锁)。另外说一下两类丢失更新：

解决：如果一个事物加上表级锁，只要有任何东西操作这个表的时候，禁止任何操作的并发

第一类事物丢失：（回滚丢失）

对于第一类事物丢失，就是比如A和B同时在执行一个数据，然后B事物已经提交了，然后A事物回滚了，这样B事物的操作就因A事物回滚而丢失了。

举个例子，比如我又1000元。买一个东西，花了100元。然后我朋友给我转了1000元。理论上这两个事物正常的话，我应该还有1900元。

但是比如现在两个A，B事物同时进行，第一步都先查询我余额还有1000元，然后B事物给我转了1000元，提交了，理论上我还有2000元。

然后我买东西，100元的，买到一半，我事物回滚，就回滚成了1000元（回滚丢失）。

如果我不回滚，也提交了，我就还剩900元（也就是下面介绍的第二类事物丢失，覆盖丢失）。

第二类事物丢失：（覆盖丢失）

对于第二类事物丢失，也称为覆盖丢失，就是A和B一起执行一个数据，两个同时取到一个数据，然后B事物首先提交，但是A事物加下来又提交，这样就覆盖了B事物，称为第二类事物丢失，覆盖丢失。

解决

对上面脏读，不可重复读，幻读，第一类事物丢失（回滚丢失），第二类事物丢失（覆盖丢失），有什么预防方法呢？

接下来讲事物的4个隔离级别：

从低到高开始：

隔离级别	脏读	不可重复读	幻读
read uncommitted（未提交读）	√	√	√
read committed（提交读）	×	√	√
repeatable read（可重复读）	×	×	√
serialization（可串行化）	×	×	×

可以看到，我们的四种隔离级别就是为了解决上面的三个问题。

1.未提交读(Read uncommitted)（写加锁，读不加锁）

写操作加写锁，读操作不加锁。禁止第一类丢失更新，但是会出现所有其他数据并发问题。

2.提交读(Read committed)（写加锁，读加锁）

写操作加写锁，读操作加读锁。禁止第一类丢失更新和脏读。

就是你已经开始读了数据，然后一个事物开始写，然后写的事物不提交的话，是不能进行读的事物，避免了脏读。

3.可重复读(Read repeatable)（写加锁，读加锁）

对于读操作加读锁到事务结束，其他事务的更新操作只能等到事务结束之后进行。和提交读的区别在于，提交读的读操作是加读锁到本次读操作结束，可重复读的锁粒度更大。禁止两类丢失更新，禁止脏读和不可重复度，但是可能出现幻读。

一个事物读的时候，我们把两次读看成整体，在读的过程中，不允许写的操作，这样就可以禁止不可重复读。就是两次读操作不允许其他事物。

这是大部分关系数据库的默认隔离级别。

4.序列化(Serializable)（对表级读写加锁）

读操作加表级读锁至事务结束。可以禁止两类丢失更新，禁止脏读，不可重复度和幻读。

隔离级别实例

提到事务，你肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即 原子性、一致性、隔离性、持久性），接下来我们就要讲解其中的I，也就是隔离性。

当数据库上存在多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了隔离级别的概念。

我们知道，隔离级别越高，效率就越低，因此我们很多情况下需要在二者之间找到一个平衡点。

SQL标准的事务隔离级别包括：

读未提交（read uncommitted）
读提交（read committed）
可重复读（repeatable read）
串行化（serializable ）

下面我逐一为你解释：

读未提交：事务中的修改，即使没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，也被称为脏读。这个级别会导致很多问题，从性能上来说也不会比其他隔离级别好很多，但却缺乏其他级别的很多好处，一般实际应用中很少用，甚至有些数据库内部根本就没有实现。
读已提交：事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的，这个级别有时候也叫做不可重复读（Nonrepeatable Read）,因为同一事务中两次执行同样的查询，可能会得到不一样的结果
可重复读：同个事务中多次查询结果是一致的，解决了不可重复读的问题。此隔离级别下还是无法解决另外一个幻读（Phantom Read）的问题，幻读是指当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，之前的事务再次读取该范围的记录时，会产生幻行
串行化：顾名思义是对于同一行记录，写会加写锁，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

对于上面的概念中，可能 读已提交 和 可重复读 比较难理解，下面会用一个例子说明这种集中隔离级别。

假设数据表T中只有一列，其中一行的值为1，下面是按照时间顺序执行两个事务的行为。

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

【JDBC第6章】数据库事务

接下来讲解不同的隔离级别下，事务A会有哪些不同的返回结果，也就是图里面V1、V2、V3的返回值分别是什么。

若隔离级别是读未提交，则V1的值就是2。这时候事务B虽然还没有提交，但是结果已经被A看到了。因此，V2、V3也都是2。
若隔离级别是读已提交，则V1是1，V2的值是2。事务B的更新在提交后才能被A看到。所以，V3的值也是2。
若隔离级别是可重复读，则V1、V2是1，V3是2。之所以V2还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
若隔离级别是串行化，则在事务B执行“将1改成2”的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看，V1、V2值是1，V3的值是2。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。

在读已提交隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，读未提交隔离级别下直接返回记录上的最新值，没有视图概念；而串行化隔离级别下直接用加锁的方式来避免并行访问。

注意一下，每种数据库的行为会有所不一样，Oracle数据库的默认隔离界别是读已提交，因此，当我们需要进行不同数据库种类之间迁移的时候，为了保证数据库隔离级别的一致，切记将MYSQL的隔离级别设置为读已提交。

操作

最后简单的给大家操作一下如何设置

session 表示当前表，global表示整个全局

select @@[session | global].tx_isolation;  //查看当前的隔离级别

set [session | global] transaction isolation level {read uncommitted | read committed | repeatable read | serializable} 

//默认级别是repeatable read

【MySQL】事务的隔离级别是如何实现的

水稻: 菜瓜，听说最近你在复习MySQL方面的知识，想请教一下MySQL的事务？

菜瓜：嗯，最近刚刚看到。事务指的是MySQL中不可拆分的业务单元，具有ACID的属性。

水稻: ACID我知道啊，但是不太懂他的实现，你能说和我聊聊事务在数据库底层是怎么实现的吗？

菜瓜：据我了解，不同的特性底层的实现不一样，主要依赖两种日志和锁来实现

先说持久性：我们知道数据的操作会先在内存中完成，那么事务提交后如何保证一定能持久化到磁盘呢
- redo log: 事务在提交前对数据的修改会先写到redo log 中，如果返回事务已提交成功，那么表示redo log已经记录完成。redo log 也有缓冲区，redo log的内存缓冲区大小和磁盘扇区的大小512字节一致，不会出现掉电易失的情况。另外redo log记录的是物理变化，体积很小，且redo log 写磁盘是顺序IO，极快~丝滑
- redo log 和binlog区别：一个是用于做持久化，另一个用作数据恢复和复制
原子性，指的是被事务包裹的一组操作要么全部成功，要么全部失败。不会存在执行了一部分，另一部分不执行的情况
- undo log: MySQL使用undo log实现操作回滚。事务开启后执行的命令都会有一条对应反向的逻辑日志计入undo日志文件中（譬如insert 就会有一条delete）。undo log的持久化会被记录在redo log中（利用redo log 速度快的特性）。一旦发生错误或者回滚的时候，利用undo就可以操作回去

水稻: 那还有一致性和隔离性呢？

菜瓜：一致性和隔离性可以放在一起说，隔离级别的选择就是一致性和隔离性的权衡

实现多个事务之间的隔离。一种是锁，另一种是mvcc机制。

水稻：锁我知道，mvcc是什么？

菜瓜：我们把数据库的读操作分为两类，一是当前读，使用锁机制；一是快照读，使用mvcc（Multi-Version Concurrency Control, 多版本并发控制）

当前读
- 数据的修改操作（insert update delete）和查询时显示加锁 select(查询条件后加上 lock in share mode & for update)
- 会锁住要读取的数据以保障数据的一致
快照读使用的是mvcc机制，就是多版本并发控制。
- 除当前读之外，普通的select查询为快照读，顾名思义，就是读取的是一个快照版本，以隔离多个事务之间的数据

水稻：能不能仔细说说这个mvcc

菜瓜：可以，它的实现还是依赖undo log来做的

在RR(Repeated Read, 可重复读) RC(Read Committed, 读提交)两种级别下使用。其他两种不需要实现隔离
你肯定听说过mysql在RR级别下解决了幻读问题，就是依赖这个来做的
- 简单来说就是，MySQL维护了一个记录活跃事务id的列表readview
- undo log是怎么记录的呢。举个栗子????
  - innodb的表中存在三个额外的隐藏字段，分别是编辑该条记录的事务id，更改前的undo log的回滚指针，还有一个对我们这个分析不太重要
  - 如果有事务对该记录做了变更，事务id会更新，同时undo log里面会产生新记录，回滚指针字段指向最新的undo log链
  - 通过比较当前事务id和readview中其他事务的id大小来决定自己读取的数据是哪个版本的undo log记录
    - 如果当前事务id比readview中的都小，就说明该条记录没有被其他事务更改。直接读取
    - 如果当前事务id比readview中的都大，沿着undo log链能找到最小事务id指向的undo log，该数据为稳定数据
- RR级别下利用该机制避免了幻读
- RC级别下每次都会读取数据的最新记录

总结：

事务的持久性和原子性由Redo log和Undo log实现
隔离性和一致性的权衡由锁机制和MVCC(Multi-Version Concurrency Control, 多版本并发控制，即快照)实现

部分内容为自己猜想，如有错误，欢迎指正！

参考文章

MySql-Undo及Redo详解 https://blog.csdn.net/aaa821/article/details/80645242
MySql MVCC 多版本并发控制 https://www.cnblogs.com/paulwang92115/p/12189487.html