数据库的事务（一）

几个概念

首先了解几个概念

MVCC(MultiVersion Concurrency Control)多版本并发控制。意思是每个SQL执行的都是在一段时间之前的数据的快照（一个数据版本），而不是当前状态的数据。他的作用是提供事务的隔离：当有并发事务更新行时，阻止查看数据的不一致性。MVCC和锁相比较的优点是读永远不会阻塞写，写也不会阻塞读。

在介绍事务隔离等级之前，先介绍下数据库几种和事务并发相关的常见的现象。在很多博客中都解释不清楚，在此本公众号力求言简意赅的解释清楚。
       脏读: A事务和B事务同时执行，均未提交，A事务可读B事务修改数据的内容。脏读比较容易理解，就不进行代码举例列。

       不可重复读: A事务中有两次查询和B事务更新数据，AB事务同时执行，B事务的执行在A事务第一次执行之后，第二次执行之前。 A两次查询的数据不一致。很多博客没说清楚的是A的两次查询在一个事务内是不一致的，这个导致用户无法理解。
不可重复读举例：

--数据库的数据是：
id, v
1, 1

--transation A
BEGIN;
SELECT id, v FROM a_table WHERE id = 1;
SELECT id, v FROM a_table WHERE id = 1;
COMMIT;

--transation B
BEGIN;
UPDATE a_table SET v=2 WHERE id = 1;
COMMIT;

--B事务的执行在A事务第一次执行之后，第二次执行之前。
--A的两次查询因为B事务已经提交，值会变得不一致。

       幻读: A事务中有两次查询和B事务插入数据，AB事务同时执行，B事务的执行在A事务第一次执行之后，第二次执行之前。 A两次查询搜索的出列不一致。 很多博客没说清楚的是A的两次查询在一个事务内是不一致的，这个导致用户无法理解。

--数据库的数据是：
id, v
1, 1
2，2

--transation A
BEGIN;
SELECT id, v FROM a_table WHERE v = 1;
SELECT id, v FROM a_table WHERE v = 1;
COMMIT;

--transation B
BEGIN;
UPDATE a_table SET v=2 WHERE id = 2;
COMMIT;

--B事务的执行在A事务第一次执行之后，第二次执行之前, 
--A第一次查询出1行，第二次查询出2行。

咋一看不可重复读和幻读有些相似，他们的区别是，
不可重复读侧重的是A查询的数据被B修改了，并且B提交了，A可以读到B修改的数据。
幻读侧重的是A查询的数据被B添加活着修改活着添加了数据，并且B提交了，A两次查询条件一致，但可以查询出被B修改后符合条件的数据行。

       非串行读取: A事务和B事务，A事务查询数据，B事务修改同一条数据，A和B事务可以同时执行。
通过上面的例子可以看出对事务的约束：非串行读取 > 幻读 > 不可重复读 > 脏读
由于取名脏、幻，给人感觉这些这些现象是不好的，事实并不是这样的。很多场景下，一个事务的提交说明业务已经完成，另一个事务完全有理由使用另一个事务修改后的数据。相反串行的情况却是比较少的。

事务隔离等级：是控制事务并发设置。事务有4个隔离级别。

与上述现象对应的就是4重隔离级别。

• 未提交可读：非串行读取、幻读、不可重复读、脏读，都存在。（postgresSQL该级别不允许脏读）。
• 已提交可读: 非串行读取、幻读、不可重复读，都存在。不允许脏读。
• 可重复读: 非串行读取、幻读，都存在。不允许脏读、不可重复读。（postgresSQL该级别不允许幻读）
• 串行化: 非串行读取。不允许脏读、不可重复读、幻读。

梳理成表格如下（postgresSQL 情况下）：

读取\隔离等级	未提交可读	已提交可读	可重复读	串行化
脏读	NO	NO	NO	NO
不可重复读	YES	YES	NO	NO
幻读	YES	YES	NO	NO
非串行读取	YES	YES	YES	NO

一般我们会选择已提交可读，在一些场景下会选择可重复读，一般不会选择串行化。串行化还有可替代方式例如SELECT FOR UDPDATE和SELECT FOR SHARE进行加锁操作。总体的效率也会比不非串行化好。