数据库隔离级别

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）	-	-	-

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

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级别。

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

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

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

     ①事务隔离性问题

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

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

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

• MVCC的作用：

  • 首先通过MVCC可以解决读写并发阻塞问题，从而提高数据的并发处理能力。
  • 其次MVCC采用的是乐观锁的方式实现，降低了死锁的概率。
  • 再者解决了一致性读的问题，也就是事务启动的时候，根据某个条件去读取到数据，直到事务结束的时候再去执行相同的条件还是读到同一份数据，不会发生变化。
  • 在使用MVCC的时候一般是根据业务场景来选择组合搭配乐观锁或者悲观锁。这两个组合中MVCC用来解决读写冲突，乐观锁或者悲观锁用来解决写和写的冲突。从而最大程度去提高数据库的并发性能。
    

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

MVCC实现原理视频链接

总结：

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

读提交解决了脏读问题，行锁解决了并发更新的问题。并且 MySQL 在可重复读级别解决了幻读问题，是通过行锁和间隙锁的组合 Next-Key 锁实现的。