谈谈数据库中事务的隔离性（isolation）

我们知道数据库在实际的运行中，通常是多个事务并发在执行的，允许多个事务并发更新数据会引起许多数据一致性的复杂问题，为了保证数据的一致性，需要额外的工作；当然我们强制事务按照串行方式执行，一个事务执行完毕，然后再开始下一个事务，这也没问题，但是系统的性能可想而知了。
多个并发事务通过合理的调度，如果最终的效果和这多个事务依次完成的效果一样，我们认为这些事务是可串行化的。在某些应用中，保证可串行性，结果可能允许极小的并发度。我们就可以采用更弱级别的一致性，当然额外的负担会由程序员来承担。
SQL标准中定义了四种的事务隔离性：
未提交读（read uncommitted）：允许读取未提交数据。
已提交读（read committed）：只允许读取已提交数据，不要求可重复读。
可重复读（repeatable read）：只允许读取已提交数据，可重复读取。
可串行性（serializable）：保证串行性。

一般而言，大部分数据库默认采用read committed隔离性。
我们就不同的隔离水平做一番测试。开启两个客户端，分别进行事务A和事务B的执行。这里我们选用MySQL数据库来做测试。Oracle同样也支持事务的不同隔离级别，不同的是Oracle不支持read uncommitted隔离级别。

read uncommitted

启动事务A

[root@localhost ~]# mysql -u hem -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 17
Server version: 8.0.16 Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use home;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |     0 |
+------+-------+
1 row in set (0.00 sec)

mysql>

启动事务B，并设置事务隔离性为read uncommitted。

[root@localhost ~]# mysql -u hem -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 18
Server version: 8.0.16 Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> set session transaction isolation level read uncommitted;
Query OK, 0 rows affected (0.00 sec)

mysql>

事务A执行数据更新。

mysql> update newtab set value=999;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql>

事务B执行查询。

mysql> use home;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |   999 |
+------+-------+
1 row in set (0.00 sec)

mysql>

事务A执行回滚。

mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |     0 |
+------+-------+
1 row in set (0.00 sec)

mysql>

事务B再次执行查询。

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |     0 |
+------+-------+
1 row in set (0.00 sec)

mysql>

read uncommitted级别的事务隔离性存在一个很大隐患，如上所述，一旦事务A回滚数据，事务B读取了事务A进行过程中的数据并进行后续的处理，结果无法预测。

read committed

修改事务B的隔离性。

mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)

事务A执行数据更新。

mysql> update newtab set value=999;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql>

事务B读取数据。

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |     0 |
+------+-------+
1 row in set (0.00 sec)

mysql>

事务A提交数据。

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql>

事务B读取数据。

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |   999 |
+------+-------+
1 row in set (0.01 sec)

mysql>

很显然，read committed隔离性的定义就是，只要事务提交了，其他事务就能看到它。想想我们在购书网站选购图书，一刷新，我们看到新的图书上架了，又一刷新，我们看到一些图书下架了，这貌似挺符合实际情况的。在想想，我们要统计此时此刻的图书在售情况，在统计过程中，一些图书上架了，依据这个变化的数据得到的统计结果符合我们的预期吗？有可能我们期望在统计开始后，数据暂时保持一致，我们好的出精确的报表。

repeatable read

修改事务B隔离性。

mysql> set session transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)

事务B开始事务并读取数据。

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |   999 |
+------+-------+
1 row in set (0.00 sec)

事务A插入数据，并提交。

mysql> insert into newtab values(30,30);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql>

事务B再次读取数据。

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |   999 |
+------+-------+
1 row in set (0.00 sec)

事务B提交事务再次读取数据。

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from newtab;
+------+-------+
| id   | value |
+------+-------+
|   43 |  999 |
|   30 |    30 |
+------+-------+
2 rows in set (0.00 sec)

mysql>

很显然，在事务B开始事务后，事务A提交的数据对事务B来讲没有任何影响。事务B开始其事务后，它读取的数据就是其开始事务时的数据快照了。

我们最后看看隔离性最高的，性能最差的serializable级别。

serializable

清除表数据，修改事务B的隔离性，并启动事务B，读取数据。

mysql> delete from newtab;
Query OK, 2 rows affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.01 sec)

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from newtab;
Empty set (0.00 sec)

mysql>

事务A插入数据。由于串行隔离的设置，事务A被阻塞，并显示lock的超时错误提示。

mysql> insert into newtab values(40,40);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql>

事务B提交事务。

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql>

事务A插入数据。

mysql> insert into newtab values(40,40);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

serializable隔离性的设置保证了事务的串行执行，但是对于并发事务的处理效率是非常低的。

这里的事务隔离性都是针对的读操作，对于写操作，一定是排他和互斥的。