[InnoDB系列] - 实例解析Innodb的隔离级别以及锁模式

简介:
1、隔离级别为:READ COMMITTED
READ COMMITTED

一个有些象Oracle的隔离级别。所有SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE
MOD语句仅锁定索引记录,而不锁定记录前的间隙,因而允许随意紧挨着已锁定的记录插入新记录。UPDATE和DELETE语句使用一个带唯一搜索条件的唯一的索引仅锁定找到的索引记录,而不包括记录前的间隙。在范围类型UPDATE和DELETE语句,InnoDB必须对范围覆盖的间隙设置next-key锁定或间隙锁定以及其它用户做的块插入。这是很必要的,因为要让MySQL复制和恢复起作用,“幽灵行”必须被阻止掉。

持续读行为如同在Oracle中:即使在同一事务内, 每个持续读设置并读取它自己的新快照。请参阅15.2.10.4节,“持续非锁定读”
show global variables like ‘tx_isolation ';
| tx_isolation  | READ-COMMITTED |
看看实测步骤:



session 1

session 2

begin

 

 

begin

select * from v where id=1;

| id  
| name   |

|   
1 | name11 |

 

 

select * from v where id=1;

| id  
| name   |

|   
1 | name11 |

select * from v where id=1 lock in share
mode;

| id  
| name   |

|   
1 | name11 |

 

 

select * from v where id=1 lock in share
mode;

| id  
| name   |

|   
1 | name11 |

 

session1 sesssion2 请求的都是共享锁,不会互斥,因此无需等待。

select * from v where id=1 for update;

| id  
| name   |

|   
1 | name11 |

 

这个时候,由于 session2 发起了 lock in share mode ,需要请求一个共享锁,和 for update 所需要的排它锁是互斥的,因此 session1 需要等待 session2 提交或回滚才能继续。

 

 

commit;

 

select * from v where id=1;

| id  
| name   |

|   
1 | name11 |

 

select * from v where id =1 for update;

或者

select * from v where id =1 lock in share
mode;

update v set name = 'name 2' where id=1;

session1 首先发起了一个 select ..for update 请求,会对该记录加一个排它锁,因此 session2 的请求会被等待,直到 session1 提交或者回滚。

commit;

 

| id  
| name   |

|   
1 | name 2 |

select * from v where id =1;

| id  
| name   |

|   
1 | name 2 |

 

 

select * from v where id =1;

| id  
| name   |

|   
1 | name11 |

 

select * from v where id =1 lock in share
mode;

| id  
| name   |

|   
1 | name 2 |

 

可以看到,如果只是发起最简单的 select 请求,则返回的结果是 session2 发生时看到的快照;如果发起一个 select…for update select..lock in share mode ,则可以看到最新的快照。

这是因为 select…for update select…lock share mode 会取得最新快照,并且请求加一个排它或者共享 next-key 锁。而普通的 select 查询不会请求加任何锁。

 

update v set name = ‘name 1’ where id =1;

commit;

select * from v where id=1;

| id  
| name   |

|   
1 | name 1 |

 

可以看到 session2 提交后的最新结果。

 

 

select * from v where id=1;

| id  
| name   |

|   
1 | name 1 |

 

可以看到 session2 提交后的最新结果。

2、隔离级别为:REPEATABLE READ

REPEATABLE READ

这是InnoDB的默认隔离级别。带唯一搜索条件使用唯一索引的SELECT ... FOR UPDATE, SELECT ... LOCK IN
SHARE MODE, UPDATE
和DELETE语句只锁定找到的索引记录,而不锁定记录前的间隙。用其它搜索条件,这些操作采用next-key锁定,用next-key锁定或者间隙锁定锁住搜索的索引范围,并且阻止其它用户的新插入。

在持续读中,有一个与之前隔离级别重要的差别:在这个级别,在同一事务内所有持续读读取由第一次读所确定的同一快照。这个惯例意味着如果你在同一事务内发出数个无格式SELECT语句,这些SELECT语句对相互之间也是持续的,请参阅15.2.10.4节,“持续非锁定读”。 

show global variables like ‘tx_isolation ';
| tx_isolation  | REPEATABLE-READ |
看看实测步骤:


session 1

session 2

begin;

 

 

begin;

select * from v where id=1 lock in share
mode;

| id  
| name   |

|   
1 | name 1 |

 

 

select * from v where id=1 lock in share
mode;

| id  
| name   |

|   
1 | name 1 |

 

session1 sesssion2 请求的都是共享锁,不会互斥,因此无需等待。

select * from v where id=1 for update;

| id  
| name   |

|   
1 | name 1 |

 

这个时候,由于 session2 发起了 lock in share mode ,需要请求一个共享锁,和 for update 所需要的排它锁是互斥的,因此 session1 需要等待 session2 提交或回滚才能继续。

 

 

commit;

 

begin;

 

select * from v where id=1;

| id  
| name   |

|   
1 | name 1 |

update v set name='name 2' where id=1;

 

 

select * from v where id=1 for update;

select * from v where id =1 lock in share
mode;

 

session1 首先发起了一个 select ..for update 请求,会对该记录加一个排它锁,因此 session2 的请求会被等待,直到 session1 提交或者回滚。

commit;

 

 

| id  
| name   |

|   
1 | name 2 |

select * from v where id=1;

| id  
| name   |

|   
1 | name 2 |

 

 

select * from v where id=1 lock in share
mode;

| id  
| name   |

|   
1 | name 2 |

 

select * from v where id=1;

| id  
| name   |

|   
1 | name 2 |

 

这个时候,不管是 select…lock in
share mode
还是 select…for update ,得到的结果都是 session 1 更新后提交的数据。

 

update v set name = 'name 1' where id=1;

select * from v where id=1;

| id  
| name   |

|   
1 | name 2 |

 

 

commit;

 

select * from v where id=1 ;

| id  
| name   |

|   
1 | name 1 |

select * from v where id=1 ;

| id  
| name   |

|   
1 | name 1 |

 

关于锁,摘取手册中的几条,更具体的请看mysql手册," 存储引擎和表类型" => " 在InnoDB中不同SQL语句设置的锁定" 这节。
·  SELECT ...
FROM
是一个持续读,读取数据库的快照并且设置不锁定,除非事务隔离级别被设为SERIALIZABLE。对于
SERIALIZABLE级别,这个设置对它遇到的索引记录设置共享的next-key锁定。

·  SELECT ... FROM ... LOCK IN SHARE
MODE
对读遇到的所有索引记录设置共享的next-key锁定。

·  SELECT ... FROM ... FOR
UPDATE
对读遇到的所有索引记录设置独占的next-key锁定。

本文转自叶金荣51CTO博客,原文链接:http://blog.51cto.com/imysql/308659,如需转载请自行联系原作者
相关文章
|
8天前
|
弹性计算 缓存 应用服务中间件
阿里云服务器2核2G99元和2核4G199元实例规格性能及适用场景解析
2024年阿里云推出了两款云服务器,2核2G3M带宽40G ESSD Entry盘价格只要99元1年,2核4G5M带宽80G ESSD Entry盘价格只要199元1年,这两款云服务器的活动截止日期为2026年3月31日,活动期间新购、续费同价。那么这两款云服务器怎么样呢?可以用来做什么?本文将对这两款云服务器进行深度解析,包括配置介绍、实例规格、使用场景以及购买建议,以供选择参考。
阿里云服务器2核2G99元和2核4G199元实例规格性能及适用场景解析
|
17天前
|
程序员 数据库 微服务
长事务管理不再难:Saga模式全面解析
本文介绍了分布式事务中的Saga模式,它用于解决微服务架构下的事务管理问题。Saga通过一系列本地事务和补偿操作确保最终一致性,分为编排和协同两种模式。文章重点讲解了编排模式,其中 Saga 协调者负责事务的执行和失败后的补偿。Saga 模式适用于业务流程明确且需要严格补偿的场景,能有效管理长事务,但实现上可能增加复杂性,并存在一致性延迟。文章还讨论了其优缺点和适用场景,强调了在面对分布式事务挑战时,Saga 模式的价值和潜力。
44 6
|
18天前
|
Prometheus 监控 关系型数据库
数据库同步革命:MySQL GTID模式下主从配置的全面解析
数据库同步革命:MySQL GTID模式下主从配置的全面解析
73 0
|
8天前
|
存储 SQL 关系型数据库
【MySQL技术内幕】6.3-InnoDB中的锁
【MySQL技术内幕】6.3-InnoDB中的锁
144 57
|
11天前
|
存储 机器学习/深度学习 编解码
深度解析阿里云服务器计算型c7与计算型c8y实例区别与选择参考
在阿里云提供的众多计算型云服务器实例规格中,计算型c7和计算型c8y实例是两款备受关注的云服务器规格。主要适用于网站应用、批量计算、视频编码等各种类型和规模的企业级应用,对于初次接触阿里云服务器的新手用户来说,可能并不是很清楚他们之间的区别,因此可能不知道怎么选择。本文将从实例的架构、处理器、存储与网络能力、使用场景、指标数据、收费标准以及实时活动价格等多个维度,对计算型c7和计算型c8y实例进行深度解析,以供参考和选择。
深度解析阿里云服务器计算型c7与计算型c8y实例区别与选择参考
|
2天前
|
弹性计算 负载均衡 API
微服务架构下的API网关模式解析
在现代软件工程中,微服务架构因其灵活性和可维护性而受到青睐。本文将探讨API网关模式在微服务架构中的关键角色,分析其设计原则、实现方式及面临的挑战,并结合实际案例阐述如何有效整合API网关以提升系统整体性能和安全性。
|
21天前
|
存储 Java
JAVA中的变量:深入解析与实例
JAVA中的变量:深入解析与实例
34 3
|
28天前
|
存储 API Python
Python文件操作:深入解析与实例
Python文件操作:深入解析与实例
103 3
|
18天前
|
存储 安全 测试技术
网络奇谭:虚拟机中的共享、桥接与Host-Only模式解析
网络奇谭:虚拟机中的共享、桥接与Host-Only模式解析
22 0
|
18天前
|
消息中间件 存储 Kafka
深入解析Kafka中的动态更新模式
深入解析Kafka中的动态更新模式
19 0

热门文章

最新文章

推荐镜像

更多