数据库隔离级别-Toy模板网

这篇具有很好参考价值的文章主要介绍了数据库隔离级别。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1. 数据库隔离级别

1.1 事务

事务只是一个改变，是一些操作的集合；用专业的术语讲，他就是一个程序的执行单元；事务本身其实并不包含这4个特性，只是我们需要通过某些手段，尽可能的让这个执行单元满足这四个特性，那么我们就可以称它为一个事务，或者说是一个正确的事务，完美的事务。

1.2 四个特性(ACID)

原子性：满足原子操作单元，对数据的操作，要么全部执行，要么全部失败。

一致性：事务开始和完成，数据都必须保持一致

隔离性：事务之间是相互独立的，中间状态对外不可见

持久性：数据的修改是永久的

1.3 隔离级别

1.3.1 并发情况下事务引发的问题

一般情况下，多个单元操作并发执行，会出现这么几个问题

脏读：A事务还未提交，B事务就读到了A事务的结果。(破坏了隔离性)

不可重复读：A事务在本次事务中，对自己未操作过的数据，进行了多次读取，结果出现了不一致或记录不存在的情况。(破坏了一致性，update和delete)

幻读：A事务在本次事务中，对自己未操作过的数据，进行了多次读取，第一次读取时，记录不存在，第二次读取时，记录出现了。(破坏了一致性，insert)

1.3.2 解决(指定标准)

为了权衡【隔离】和并发的矛盾，IOS定义了四个事务的隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同。

读未提交（read-uncommitted）：最低一级别，只能保证持久性

读已提交（read-committed）：语句级别的

可重复读（repeatable-read）：事务级别的

串行化（serializable）：最高级别，事务与事务完全串行化执行，毫无并发可言，性能极低。

事务隔离级别脏读不可重复读幻读

读未提交（read-uncommitted）会会会

读已提交（read-committed） - 会会

可重复读（repeatable-read） - - 会

串行化（serilizable） - - -

注意：这四个级别只是一个标准，各个数据库厂商，并不是完全按照这个标准来做的。

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	会	会	会
读已提交（read-committed）	-	会	会
可重复读（repeatable-read）	-	-	会
串行化（serilizable）	-	-	-

1.3.3 用SQL语句模拟数据库隔离级别

创建数据库及账户表语句

CREATE TABLE account (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    balance DECIMAL(19 , 4 ) NOT NULL
);

insert into account(name,balance) 
VALUES('张三',200),
('李四',500);

mysql默认开启自动提交事务

#查看是否开启自动提交事务的功能(0：禁用，1：开启)
select @@autocommit;
#禁用自动提交事务的功能
set autocommit = 0;

mysql默认隔离级别为可重复读

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}。

#查看事务隔离级别  mysql8以前(TX_ISOLATION;)  mysql8.0及之后(transaction_isolation) 
select @@transaction_isolation;  # -->REPEATABLE-READ
# 或者 show variables like '%isolation%';  
#设置当前mysql连接的隔离级别:
set session transaction isolation level read uncommitted;
#设置数据库系统的全局的隔离级别为读未提交:
set global transaction isolation level read uncommitted;

注：全局设置完毕后需要重新连接数据库查看才能看到隔离级别的改变。
数据库隔离级别

read uncommitted（读未提交）性能最好，不加锁，可以理解为没有隔离。

开启两个窗口分别为事务A和事务B
事务A

#开启事务 即commit/rollback之后再执行修改操作，还需执行开启事务。
start transaction;#或者begin;
#张三让李四V他50，买皮肤
update account set balance = balance + 50 where name = '张三';
#李四V张三50
update account set balance = balance - 50 where name = '李四';
select * from account;
#李四老婆要买口红，让李四不要转钱给张三，把钱留着给她买口红，于是李四进行了回滚操作
rollback;

事务B

start transaction; //或者begin;
#事务B执行修改时先查询一次，执行完修改后再查询一次
select * from account;

数据库隔离级别

read committed（读已提交）

设置事务当前会话的隔离级别为read committed。
事务C

#设置数据库系统当前会话的隔离级别为读已提交:
set session transaction isolation level read committed;
begin;
#李四老婆用李四的账户去买口红
update account set balance=balance-480 where name = '李四';
commit;

事务A

set session transaction isolation level read committed;
begin;
#下班前李四先查看余额，有那么多钱，准备在公司楼下吃碗牛肉肥肠面，与此同时李四老婆正付钱买口红还未提交，到楼下后李四再次查看钱还未变动；
select * from account;
#终于到面馆，此时李四老婆已经支付成功，李四再查看，只剩20元只能吃个牛肉面。
select * from account;

数据库隔离级别

repeatable read（可重复读）

事务A

#设置数据库系统的全局的隔离级别为读已提交:
set session transaction isolation level repeatable read;
begin;
update account set balance=balance-18 where name = '李四';
commit;

事务C

set session transaction isolation level repeatable read;
begin;
select * from account;
#李四交钱后
select * from account;

数据库隔离级别

serializable（串行化）读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。
- 事务A
```
set session transaction isolation level serializable;
begin;
#李四查询钱包余额
select * from account;
```
- 事务C
```
set session transaction isolation level serializable;
begin;
#李四老婆查询李四钱包余额，发现没钱了，准备给他转1k
select * from account;
update account set balance=balance+1000 where name = '李四';
```
- （在事务A还未执行commit时，执行update操作account表会进行等待，在限定时间内（测试为50秒）事务A提交，则事务C执行update完成，否则会发生error，ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction超过锁定等待超时；尝试重新启动事务)，可以使用 SELECT * FROM information_schema.INNODB_TRX; 查询是否有正在锁定的事务线程。）

1.3.4 实现(InnoDB)

锁机制：阻止其他事务对数据进行操作，各个隔离级别主要体现在读取数据时加的锁和释放时机。

RU：事务读取的时候，不加锁

RC：事务读取的时候加行级共享锁（读到才加锁），一旦读完，立刻释放（并不是事务结束）。

RR：事务读取时加行级共享锁，直到事务结束才会释放。

SE：事务读取时加表记共享锁，直到事务结束时，才会释放。

MVCC机制：全称Multi-Version Concurrency Control(多版本并发控制) 的方式。MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读写冲突。主要作用于RC和RR级别。

从数据库的三个并发场景出发：

读和读的并发：线程A和B同时进行读操作，这种情况不会产生任何的并发问题。

读写并发：线程A和B在同一时刻，分别进行读写操作，这种情况下可能会对数据库的数据造成以下问题：

①事务隔离性问题

②会出现脏读、幻读、不可重复读的问题

写和写的并发：线程A和B同时进行写操作，这种情况可能存在数据更新的丢失问题。

MVCC就是为了解决事务操作中，并发安全问题的无锁并发控制技术，通过数据库中的隐式字段按Undo日志和Read View来实现的。

MVCC的作用：

首先通过MVCC可以解决读写并发阻塞问题，从而提高数据的并发处理能力。

其次MVCC采用的是乐观锁的方式实现，降低了死锁的概率。

再者解决了一致性读的问题，也就是事务启动的时候，根据某个条件去读取到数据，直到事务结束的时候再去执行相同的条件还是读到同一份数据，不会发生变化。

在使用MVCC的时候一般是根据业务场景来选择组合搭配乐观锁或者悲观锁。这两个组合中MVCC用来解决读写冲突，乐观锁或者悲观锁用来解决写和写的冲突。从而最大程度去提高数据库的并发性能。

为了解决不可重复读，或者为了实现可重复读，MySQL 采用了 MVVC ，全称Multi-Version Concurrency Control(多版本并发控制) 的方式。MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

MVCC实现原理视频链接

总结：

读未提交和串行化基本上是不需要考虑的隔离级别，前者不加锁限制，后者相当于单线程执行，效率太差。

读提交解决了脏读问题，行锁解决了并发更新的问题。并且 MySQL 在可重复读级别解决了幻读问题，是通过行锁和间隙锁的组合 Next-Key 锁实现的。文章来源地址https://www.toymoban.com/news/detail-467697.html