关于数据库:数据库事务的四大特性以及事务的隔离级别整理

34次阅读

共计 3468 个字符，预计需要花费 9 分钟才能阅读完成。

原子性（atomicity）

咱们常常说，一个事务执行失败了，就得回滚，其实这就是事务的原子性，一个残缺事务，要么全副执行胜利，如果有一个或者多个失败，那么就要回滚，其实这也是另一个个性即一致性的根底

一致性（consistency）

一致性，先举个栗子，最容易了解的栗子，原本刘备有 200 元，关羽没有钱，那么刘备给关羽转账 100 元，当初须要两步执行这个操作，先减去刘备账户外面的 100 元，第二步，给关羽账号减少 100 元，那么这两步算是一个事务。在事务产生前，关羽 0 + 刘备 200=200 元，事务完结后，关羽 100+ 刘备 100=200，数据没有平白减少或者缩小。而且不论这兄弟俩怎么转，这个总和不会发生变化，这就是事务的一致性。一致性就是说事务必须应用数据库从一个一致性状态变换到另一个一致性状态。想想咱们讲的第一个原子性，如果一半胜利，一半失败而没有回滚，还会有数据的一致性吗？

隔离性（isolation）

隔离性次要是针对并发拜访来讲的，当多个用户批改数据表时，数据库为每一个用户开启的事务，不能被其余的事务烦扰，多个并发要相互隔离，即对于同一个资源，在同一个时间段只能有一个事务能够批改

持久性 (durability)

持久性就是说一旦事务胜利提交，那么对于数据库来说，这种扭转是长久的

在 mysql 中，反对四种隔离级别，即 ru,rc，rr,serializealbe，前面咱们会一一解说，mysql 默认反对的的 rr,

此处给大家举荐一款好用的数据库管理工具,jetbrains 出品的 datagrip；好用哇哇！，上面的 sql 语句都是在 datagrip 中运行的

READ UNCOMMITTED（未提交读）
ru 是指在一个事务执行未实现的时候，数据对其余事务也是可见的，而且读取的是曾经更改然而还没有 commit 的数据，这种保障不了数据精确的隔离级别简直是不必的。也正如此，所以它的性能是最优的
- 创立相干的数据库和数据表

create schema test;
use test;
CREATE TABLE `t` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
                     `point` int(11) DEFAULT NULL,
                     PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

上面粘贴 sql 语句，留神在同一行的代码先左后右执行，是在两个 sql 窗口执行的, 在执行到第 6 行的时候发现，console2 开启了事务，然而还没有 commit，然而 console1 曾经查问到未提交的后果了。这就是读未提交

READ COMMITTED（读已提交）

大部分的数据库默认隔离级别就是 rc, 就是说一个事务只能看见曾经提交的批改后果，如果没有提交，那么只能看见原来的后果，而不会看到批改未提交的后果，然而这会呈现一个问题，什么问题呢？就是在一个事务中，如果另一个事务批改了数据并且提交，那么在第一个事务中针对同一个查问，就会查问进去两个不同的数据，即不可反复读

新增一条如果没有提交也是读取不到的

这个时候，如果两个窗口同时对一条数据更改会产生什么状况呢？第二条更新命令会始终等第一条命令的提交，未提交就处于期待状态

REPEATABLE READ（可反复读）
可反复读是 mysql 默认的隔离级别，rr 解决了脏读的问题，然而可能会呈现幻读，上面先来演示一下幻读的实现
- 看一下曾经解决了读未提交的问题和不可反复读的问题

幻读其实是解决不可反复读的一个毛病，为什么？首先事务 1 曾经执行了一个插入操作，新增 id3，然而为了可反复读，事务 2 看不到新增的数据，所以当事务 2 减少 id3 的时候报错，因为 id3 在数据表中曾经切切实实的存在了。可反复读，有点像把某一个时刻的数据作为快照写入了缓存，在 commit 之前所有的读取都是源自缓存，而非实在的表

其实咱们能够先本人想一下，如何在解决反复读的时候还能解决幻读呢？是不是感觉有点不可能，既然不幻读，那就实现不了可反复读，然鹅，然而，后面的操作都是基于两个事务，然而如咱们把两个事务再关联一下呢，是不是就能够解决了，这就是串行的意思，可串行化解决了脏读，幻读，可反复读等问题，然而，势必会影响效率，” 可串行化 ” 会在读取的每一行数据上都加锁，所以可能会导致大量的锁期待和超时问题，所以在理论的生产环境中也很少会用到这个隔离级别，只有在十分须要确保数据的一致性切能够承受没有并发的状况下，才会思考应用这个隔离级别。

演示一下, 先看一下目前的状况

怎么实现串行化呢，说起来有点恶心，这次不是缓存快照了，让你读实时数据，然而更新操作我给你停了。我让你等到没有事务了，或者其余事务都提交了，才让你这个写操作执行，嗯，就是这样。感觉有点不太高明

用了锁，有人读也上锁，有人写也上锁，效率能没有影响吗，写之前先看有没有读锁，有读锁就期待。这种形式就是简略，粗犷

综合下来，还是看应用的业务场景抉择不同的隔离级别，个人感觉大部分业务还是用 rc 比拟好。你感觉呢？

附 sql 脚本
console1.sql

use test;
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
#READ UNCOMMITTED（未提交读）start transaction ;
select * from t where id =1;
update t set point=50 where id =1;
commit ;
#READ COMMITTED（读已提交）SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
select * from t where id =1;
start transaction ;
update t set point=80 where id =1;
insert into t values (null,200);
select * from t where id =2;
commit ;

#REPEATABLE READ（可反复读）SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ ;
select * from t ;
start transaction ;
update t set point=100 where id=1;
commit ;

start transaction ;
select * from t ;
insert into t values (null,300);
select * from t ;
commit


## SERIALIZABLE（可串行化）SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
start transaction ;
select * from t;
insert into t values (null,123);

console2.sql

use test;
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
#READ UNCOMMITTED（未提交读）start transaction ;
select * from t where id =1;
select * from t where id =1;
commit ;
#READ COMMITTED（读已提交）SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
select * from t where id =1;
start transaction ;
update t set point=10 where id =1;
select * from t where id =1;
select * from t where id =2;
commit ;

#REPEATABLE READ（可反复读）SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ ;
select * from t ;
start transaction ;
select * from t where id=1;
select * from t where id=1;

start transaction ;
select * from t ;
select * from t ;
insert into t values (3,300);
commit


## SERIALIZABLE（可串行化）SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE ;
start transaction ;
select * from t；commit;

本篇文章由一文多发平台 ArtiPub 主动公布

正文完