MySQL 系列（三）事务

一组要么同时执行成功，要么同时执行失败的 SQL 语句。是数据库操作的一个执行单元!

事务开始于：

1. 连接到数据库上，并执行条 DML 语句(INSERT、 UPDATE 或 DELETE)。
2. 前一个事务结束后，又输入了另外一条 DML 语句。

如果 JDBC 连接是在自动提交模式下，它在默认情况下，那么每个 SQL 语句都是在其完成时提交到数据库。

事务结束于：

1. 执行 COMMIT 或 ROLLBACK 语句
2. 执行条 DDL 语句，例如 CREATE TABLET 语句；在这种情况下，会自动执行 COMMIT 语句
3. 执行 DCL 语句，例如 GRANT 语句；在这种情况下，会自动执行 COMMIT 语句
4. 断开与数据库的连接
5. 执行了一条 DML 语句，该语句却失败了；在这种情况中，会为这个无效的 DML 语句执行 ROLLBACK 语句

下面的例子演示了如何使用一个提交和回滚对象：

try{

    // Assume a valid connection object conn

    conn.setAutoCommit(false);

    Statement stmt = conn.createStatement();

    String SQL = "INSERT INTO Employees "VALUES (106, 20, 'Rita', 'Tez')";

    stmt.executeUpdate(SQL);

    // Submit a malformed SQL statement that breaks

    String SQL = "INSERTED IN Employees "VALUES (107, 22, 'Sita', 'Singh')";

    stmt.executeUpdate(SQL);

    // If there is no error.

    conn.commit();

}catch(SQLException e){

    // If there is any error.

    conn.rollback();

}

一、事务的四大特点(ACID)

1. atomicity(原子性)

   表示一个事务内的所有操作是一个整体，要么全部成功，要么全失败。

2. consistency(一致性)

   表示个事务内有一个操作失败时，所有的更改过的数据都必须回滚到修改前的状态。

3. isolation(隔离性)

   事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会直看中间状态的数据。

4. durability(持久性)

   持久性事务完成之后，它对于系统的影响是永久性的。

二、事务的 4 种隔离级别

数据库事务的隔离级别由低到高有以下 4 种：

1. 读取未提交(Read Uncommitted)
2. 读取已想交(Read Committed)
3. 可重复读(Repeatable Read)
4. 序列化(serializable)

在事务的并发操作中可能会出现脏读，不可重复读，幻读。下面通过事例一一阐述它们的概念与联系。

2.1 Read uncommitted

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。

事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。

分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。 这就是脏读。

那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。

2.2 Read committed

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（第二次检测金额当然要等待妻子转出金额事务提交完）。程序员就会很郁闷，明明卡里是有钱的…

分析：这就是读提交，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

那怎么解决可能的不可重复读问题？Repeatable read ！

2.3 Repeatable read

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。

事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即 UPDATE 操作。但是可能还会有幻读问题。因为幻读问题对应的是插入 INSERT 操作，而不是 UPDATE 操作。

什么时候会出现幻读？

事例：程序员某一天去消费，花了 2 千元，然后他的妻子去查看他今天的消费记录（全表扫描 FTS，妻子事务开启），看到确实是花了 2 千元，就在这个时候，程序员花了1万买了一部电脑，即新增 INSERT 了一条消费记录，并提交。当妻子打印程序员的消费记录清单时（妻子事务提交），发现花了 1.2 万元，似乎出现了幻觉， 这就是幻读。

那怎么解决幻读问题？Serializable！

2.4 Serializable 序列化

Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

值得一提的是：大多数数据库默认的事务隔离级别是 Read committed，比如 Sql Server , Oracle。Mysql 的默认隔离级别是 Repeatable read。

参考：

《事务的隔离级别》：https://segmentfault.com/a/1190000004469395

---

每天用心记录一点点。内容也许不重要，但习惯很重要！