[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月前
|
监控 安全 数据可视化
哪些项目适合采用BOT+EPC模式?深度解析
2分钟了解什么是BOT+EPC项目管理模式以及该模式适用于哪些类型的项目。
650 1
哪些项目适合采用BOT+EPC模式?深度解析
|
7月前
|
数据可视化 算法 数据挖掘
用傅里叶变换解码时间序列:从频域视角解析季节性模式
本文介绍了如何使用傅里叶变换和周期图分析来识别时间序列中的季节性模式,特别是在能源消耗数据中。通过Python实现傅里叶变换和周期图,可以有效提取并量化时间序列中的主要和次要频率成分,克服传统可视化分析的局限性。这对于准确捕捉时间序列中的季节性变化具有重要意义。文章以AEP能源消耗数据为例,展示了如何应用这些方法识别日、周、半年等周期模式。
322 3
用傅里叶变换解码时间序列:从频域视角解析季节性模式
|
7月前
|
数据采集 Web App开发 存储
深度解析:使用 Headless 模式 ChromeDriver 进行无界面浏览器操作
本文介绍了基于无界面浏览器(如ChromeDriver)和代理IP技术的现代爬虫解决方案,以应对传统爬虫面临的反爬机制和动态加载内容等问题。通过Selenium驱动ChromeDriver,并结合亿牛云爬虫代理、自定义Cookie和User-Agent设置,实现高效的数据采集。代码示例展示了如何配置ChromeDriver、处理代理认证、添加Cookie及捕获异常,确保爬虫稳定运行。性能对比显示,Headless模式下的ChromeDriver在数据采集成功率、响应时间和反爬规避能力上显著优于传统爬虫。该方案广泛应用于电商、金融和新闻媒体等行业。
421 0
深度解析:使用 Headless 模式 ChromeDriver 进行无界面浏览器操作
|
8月前
|
CDN
阿里云CDN怎么收费?看这一篇就够了,CDN不同计费模式收费价格全解析
阿里云CDN的费用由基础费用和增值费用组成。基础费用有三种计费方式:按流量、按带宽峰值和月结95带宽峰值,默认为按流量计费,价格根据使用量阶梯递减。增值费用包括静态HTTPS请求、QUIC请求等,按实际使用量收费,不使用不收费。具体收费标准和详细规则可参考阿里云官方页面。
|
10月前
|
数据采集 机器学习/深度学习 数据挖掘
10种数据预处理中的数据泄露模式解析:识别与避免策略
在机器学习中,数据泄露是一个常见问题,指的是测试数据在数据准备阶段无意中混入训练数据,导致模型在测试集上的表现失真。本文详细探讨了数据预处理步骤中的数据泄露问题,包括缺失值填充、分类编码、数据缩放、离散化和重采样,并提供了具体的代码示例,展示了如何避免数据泄露,确保模型的测试结果可靠。
644 2
|
11月前
|
人工智能 数据挖掘 大数据
排队免单与消费增值模式:融合玩法与优势解析
排队免单模式通过订单排队、奖励分配、加速与退出机制等,结合消费增值模式中的积分制度、利润入池与积分增值等,共同提升消费者参与度和忠诚度,促进商家销售增长。具体包括订单自动排队、大单拆小单、异业联盟、线上线下融合及数据分析优化等进阶玩法,以及积分增值模型演算,形成一套完整的消费者激励体系。
|
11月前
|
存储 安全 Java
JVM锁的膨胀过程与锁内存变化解析
在Java虚拟机(JVM)中,锁机制是确保多线程环境下数据一致性和线程安全的重要手段。随着线程对共享资源的竞争程度不同,JVM中的锁会经历从低级到高级的膨胀过程,以适应不同的并发场景。本文将深入探讨JVM锁的膨胀过程,以及锁在内存中的变化。
149 1
|
设计模式 存储 安全
PHP中单例模式的深入解析与实践指南
在PHP开发领域,设计模式是构建高效、可维护代码的重要工具。本文聚焦于单例模式——一种确保类仅有一个实例,并提供全局访问点的模式。我们将从理论出发,探讨单例模式的基本概念、应用场景,并通过实际案例分析其在PHP中的实现技巧。最后,讨论单例模式的优势、潜在缺陷及如何在实际项目中合理运用。
|
安全 Java 开发者
Java并发编程中的锁机制解析
本文深入探讨了Java中用于管理多线程同步的关键工具——锁机制。通过分析synchronized关键字和ReentrantLock类等核心概念,揭示了它们在构建线程安全应用中的重要性。同时,文章还讨论了锁机制的高级特性,如公平性、类锁和对象锁的区别,以及锁的优化技术如锁粗化和锁消除。此外,指出了在高并发环境下锁竞争可能导致的问题,并提出了减少锁持有时间和使用无锁编程等策略来优化性能的建议。最后,强调了理解和正确使用Java锁机制对于开发高效、可靠并发应用程序的重要性。
113 3
|
11月前
|
前端开发 算法 JavaScript
无界SaaS模式深度解析:算力算法、链接力、数据确权制度
私域电商的无界SaaS模式涉及后端开发、前端开发、数据库设计、API接口、区块链技术、支付和身份验证系统等多个技术领域。本文通过简化框架和示例代码,指导如何将核心功能转化为技术实现,涵盖用户管理、企业店铺管理、数据流量管理等关键环节。

热门文章

最新文章

推荐镜像

更多
  • DNS