共计 3904 个字符，预计需要花费 10 分钟才能阅读完成。
概念介绍
事物：用来保障一组操作，要么全副胜利要么全副失败隔离：因为在高并发状况下大概率会呈现多个事物同时操作同一个数据，如果事物之间不进行隔离可能会呈现意想不到的问题
InnoDB 四种事物隔离级别
针对并发状况下的多事物之间相互影响的问题 Mysql 提供了四种事物隔离级别，别离如下:
-
读未提交（READ_UNCOMMITTED）容许读取其余事物未提交的写操作；
因而如果其余事物做了回滚那么对于以后事物来说读到的数据就是脏数据 -
读已提交（READ_COMMITTED）只容许读取其余事物已提交的操作；
在同一个事物内屡次读取到的数据不能保持一致，也就是不可反复读 -
可反复读（REPEATABLE_READ）只能读取事物开启时的数据状态
该隔离级别下能够保障每次读到的数据是统一的，然而如果事物内要插入却会呈现主键抵触 -
序列化（SERIALIZABLE）最高级隔离，事物操作串行化执行，不能最大化利用数据库资源，吞吐量很低
实战
1. 数据筹备
## 首先创立一张企业账户表
create table corp_account
(
id int not null,
account_name varchar(20) not null comment '账户名',
amount decimal default 0.0 comment '账户余额',
constraint corp_account_pk
primary key (id)
)
comment '企业账户表';
## 插入一条数据
INSERT INTO test.corp_account (id, account_name, amount) VALUES (1, 'cocoo', 100);2. 验证各隔离级别下 脏读 、 不可反复读 和幻读 的问题
2.1 读未提交：READ-UNCOMMITTED
## 开启一个事物:A
START TRANSACTION;
## 批改 amount 为 90
update corp_account set amount = 90 where id = 1;
## 此时本事物内查问 amount 为 90
select * from corp_account where id = 1;
## 不提交该事物
rollback ; ## 这句暂不执行在事物 A 没提交的前提下，新开一个数据库连贯的 session
## 设置本 session 的事物隔离级别为读未提交
set tx_isolation = 'READ-UNCOMMITTED';
## 查问本 session 的事物隔离级别，确认事物隔离级别是否批改胜利
SELECT @@tx_isolation;
## 开启一个新事物:B
START TRANSACTION;
## 查问 id 为 1 的记录，显示 amount=90，阐明读取到了事物 A 未提交的数据
## 此时如果事物 A 执行回滚(rollback)，事物 B 拿到的这个 90 就是脏数据了
select * from corp_account where id = 1;总结：
读未提交会呈现脏读的问题
2.2 读已提交: READ-COMMITTED
## 开启一个事物:A
START TRANSACTION;
## 批改 amount 为 90
update corp_account set amount = 90 where id = 1;
## 此时本事物内查问 amount 为 90
select * from corp_account where id = 1;
commit ; ## 这句暂不执行同样的在事物 A 没提交的前提下，新开一个数据库连贯的 session
## 设置本 session 的事物隔离级别为读已提交
set tx_isolation = 'READ-COMMITTED';
## 查问本 session 的事物隔离级别，确认事物隔离级别是否批改胜利
SELECT @@tx_isolation;
## 开启一个新事物:B
START TRANSACTION;
## 查问 id 为 1 的记录，显示 amount=100，阐明未读取到了事物 A 未提交的数据，## 解决了读未提交中的脏读问题
select * from corp_account where id = 1;
## 事物 A 执行提交 (commit) 后，再来查问会发现 amount=90, 阐明读取到了事物 A 提交的变更
select * from corp_account where id = 1;
## 此时咱们会发现在同一个事物内两次读取同一条数据，后果不样：## 第一次读取 amount=100, 第二次读取变成 90 了，不满足数据库事物 ACID 个性的数据一致性(consistency)，即不可反复读总结：
读已提交尽管解决了读未提交中的脏读问题，然而会呈现不可反复读的问题
2.3 可反复读：REPEATABLE-READ
## 开启一个事物:A
START TRANSACTION;
## 批改 amount 为 90
update corp_account set amount = 90 where id = 1;
## 此时本事物内查问 amount 为 90
select * from corp_account where id = 1;
commit ; ## 这句暂不执行同样的在事物 A 没提交的前提下，新开一个数据库连贯的 session
## 设置本 session 的事物隔离级别为可反复读
set tx_isolation = 'REPEATABLE-READ';
## 查问本 session 的事物隔离级别，确认事物隔离级别是否批改胜利
SELECT @@tx_isolation;
## 开启一个新事物:B
START TRANSACTION;
## 1. 查问 id 为 1 的记录，显示 amount=100，阐明未读取到了事物 A 未提交的数据，## 解决了脏读问题
select * from corp_account where id = 1;
## 2. 事物 A 执行提交 (commit) 后，再来查问会发现 amount 还是 100, 阐明无奈读取到了事物 A 提交的变更
## 解决了不可反复读的问题
select * from corp_account where id = 1;
## 3. 这里会有一个疑难，既然读取不到其余事物已提交的批改，## 那如果本事物也执行更新操作不是会笼罩前一个事物已提交的数据吗？## 假如你的更新逻辑是先 select amount，而后在程序里计算出一个具体的值，再作为参数传递给 update，那的确会呈现笼罩的状况，所以只需向上面这样更新就没问题了
update corp_account set amount = amount - 10
## 4. 这是因为 RR 级别解决不可反复读的问题只是针对 select * 这种查问应用了快照读，而对于 udpate、delete、insert 这类操作应用的以后读。而幻读就是因为写操作的以后读导致了 RR 隔离级别无奈解决RR 隔离级别重现幻读
## 开启一个事物:A
START TRANSACTION;
## 新增一条 id 为 2 的数据
INSERT INTO test.corp_account (id, account_name, amount) VALUES (2, 'google', 1000);
commit ; ## 待事物 B 开启后提交同样的在事物 A 没提交的前提下，新开一个数据库连贯的 session
## 设置本 session 的事物隔离级别为可反复读
set tx_isolation = 'REPEATABLE-READ';
## 查问本 session 的事物隔离级别，确认事物隔离级别是否批改胜利
SELECT @@tx_isolation;
## 开启一个新事物:B
START TRANSACTION;
## 1. 提交事物 A
## 2. 查问 id 为 2 的记录，从下面那个例子咱们曾经晓得此时是查不到。因为事物 B 开启的时候事物 A 还没提交。## 3.1 这里页插入一条 id 为 2 的记录，上面的 insert 回报主键抵触，select 查不到 insert 却又抵触，这不就是像幻觉一样吗
INSERT INTO test.corp_account (id, account_name, amount) VALUES (2, 'google', 1000);
## 3.2 咱们还能够胜利 update 事物 A 提交的那条 ID 为 2 的数据。很魔幻，查问不到却能够批改，这就是幻读
update test.corp_account set amount = 900 where id = 2;总结：
可反复读尽管解决了读已提交中的不可反复读的问题，然而会呈现幻读
2.4 序列化：SERIALIZABLE
新开一个事物：A，批改 id 为 1 的账户金额为 80，但临时不提交
start transaction ;
update corp_account set amount = 80 where id = 1;
select * from corp_account where id = 1;
commit ; # 暂不提交同样的在事物 A 没提交的前提下，新开一个数据库连贯的 session
# 设置以后 session 的事物隔离级别为 serializable
set tx_isolation = 'serializable';
# 确认是否设置胜利
select @@tx_isolation;
# 开启新的事物：B，start transaction;
select * from corp_account where id = 1;
commit ;能够看到咱们的事物 B 只是查问 Id 为 1 的这条记录，来看下执行后果：
能够看到事物 B 里的执行逻辑被阻塞了；接着咱们把事物 A 提交了再看下事物 B 的执行后果：
此时查问出的后果刚好是事物 B 提交的，这个时候如果事物 B 不提交，再次执行事物 A，会发现事物 A 也同样会产生阻塞
总结：两个事物同时操作一个数据，只有有一个事物的隔离级别是序列化就会产生阻塞：前一个事物未提交，其余事物操作 (无论是读还是写) 会进入阻塞状态，须要等前一个事物提交后能力执行。
** 以上没有被动设置事物隔离级别的回话都默认应用了 InnoDB 数据库默认的隔离级别 - 可反复读！**