AI 助理
备案控制台
开发者社区 数据库 文章 正文

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

2017-11-22 1024
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
公共DNS（含HTTPDNS解析），每月1000万次HTTP解析
全局流量管理 GTM，标准版 1个月
云解析 DNS，旗舰版 1个月
简介：
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，如需转载请自行联系原作者
文章标签：
云解析DNS
关系型数据库
索引
SQL
MySQL
Oracle
数据库
存储
关键词：
云解析DNS实例
云解析DNS innodb
云解析DNS锁
云解析DNS模式
innodb锁
科技小先锋
目录
相关文章
那年春天
|
2月前
|
存储 负载均衡 监控
数据库多实例的深入解析
【10月更文挑战第24天】数据库多实例是一种重要的数据库架构方式，它为数据库的高效运行和灵活管理提供了多种优势。在实际应用中，需要根据具体的业务需求和技术环境，合理选择和配置多实例，以充分发挥其优势，提高数据库系统的性能和可靠性。随着技术的不断发展和进步，数据库多实例技术也将不断完善和创新，为数据库管理带来更多的可能性和便利。
那年春天
119 57
bruce_xiaowei
|
14天前
|
数据挖掘 vr&ar C++
让UE自动运行Python脚本：实现与实例解析
本文介绍如何配置Unreal Engine（UE）以自动运行Python脚本，提高开发效率。通过安装Python、配置UE环境及使用第三方插件，实现Python与UE的集成。结合蓝图和C++示例，展示自动化任务处理、关卡生成及数据分析等应用场景。
bruce_xiaowei
71 5
LuckiBit
|
1月前
|
存储 网络协议 算法
【C语言】进制转换无难事：二进制、十进制、八进制与十六进制的全解析与实例
进制转换是计算机编程中常见的操作。在C语言中，了解如何在不同进制之间转换数据对于处理和显示数据非常重要。本文将详细介绍如何在二进制、十进制、八进制和十六进制之间进行转换。
LuckiBit
39 5
弹性计算小冉
|
2月前
|
存储 机器学习/深度学习 编解码
阿里云服务器计算型c8i实例解析：实例规格性能及使用场景和最新价格参考
计算型c8i实例作为阿里云服务器家族中的重要成员，以其卓越的计算性能、稳定的算力输出、强劲的I/O引擎以及芯片级的安全加固，广泛适用于机器学习推理、数据分析、批量计算、视频编码、游戏服务器前端、高性能科学和工程应用以及Web前端服务器等多种场景。本文将全面介绍阿里云服务器计算型c8i实例，从规格族特性、适用场景、详细规格指标、性能优势、实际应用案例，到最新的活动价格，以供大家参考。
弹性计算小冉
62 2
游客44yag4ft7nckq
|
3月前
|
XML 数据格式
HTML 实例解析
本文介绍了HTML中常见元素的使用方法，包括`<p>`、`<body>`和`<html>`等。详细解析了这些元素的结构和作用，并强调了正确使用结束标签的重要性。此外，还提到了空元素的使用及大小写标签的规范。
游客44yag4ft7nckq
18 1
最好zzz
|
3月前
|
存储 安全 Java
JVM锁的膨胀过程与锁内存变化解析
在Java虚拟机（JVM）中，锁机制是确保多线程环境下数据一致性和线程安全的重要手段。随着线程对共享资源的竞争程度不同，JVM中的锁会经历从低级到高级的膨胀过程，以适应不同的并发场景。本文将深入探讨JVM锁的膨胀过程，以及锁在内存中的变化。
最好zzz
57 1
bruce_xiaowei
|
4月前
|
数据可视化 Python
Python绘制基频曲线——实例解析与应用探讨
Python绘制基频曲线——实例解析与应用探讨
bruce_xiaowei
68 9
muxiaoxi
|
4月前
|
安全 Java 开发者
Java并发编程中的锁机制解析
本文深入探讨了Java中用于管理多线程同步的关键工具——锁机制。通过分析synchronized关键字和ReentrantLock类等核心概念，揭示了它们在构建线程安全应用中的重要性。同时，文章还讨论了锁机制的高级特性，如公平性、类锁和对象锁的区别，以及锁的优化技术如锁粗化和锁消除。此外，指出了在高并发环境下锁竞争可能导致的问题，并提出了减少锁持有时间和使用无锁编程等策略来优化性能的建议。最后，强调了理解和正确使用Java锁机制对于开发高效、可靠并发应用程序的重要性。
muxiaoxi
36 3
bruce_xiaowei
|
3月前
|
数据可视化 Python
Python绘制基频曲线——实例解析与应用探讨
Python绘制基频曲线——实例解析与应用探讨
bruce_xiaowei
27 0
蓝易云
|
3月前
|
存储 缓存 关系型数据库
详细解析MySQL中的innodb和myisam
总之，InnoDB和MyISAM各有千秋，选择合适的存储引擎应基于对应用程序特性的深入理解，以及对性能、数据完整性和可扩展性的综合考量。随着技术发展，InnoDB因其全面的功能和日益优化的性能，逐渐成为更广泛场景下的首选。然而，在特定条件下，MyISAM依然保留其独特的价值。
蓝易云
185 0

热门文章

最新文章

  • 1
    Mysql索引：深入理解InnoDb聚集索引与MyisAm非聚集索引
  • 2
    MySQL引擎InnoDB和MyISAM的区别？
  • 3
    MySQL存储引擎详述：InnoDB为何胜出？
  • 4
    InnoDB为什么使用自增id作为主键？
  • 5
    “COUNT(*) MyISAM比InnoDB更快”是误解
  • 6
    OpenAI 12天发布会全解析 | AI大咖说
  • 7
    【C语言】深入浅出：C语言链表的全面解析
  • 8
    深入解析PID控制算法：从理论到实践的完整指南
  • 9
    微服务架构解析：跨越传统架构的技术革命
  • 10
    鸿蒙HarmonyOS应用开发 |鸿蒙技术分享HarmonyOS Next 深度解析：分布式能力与跨设备协作实战
  • 1
    【Uniapp 专栏】Uniapp 的状态管理功能深度解析
    362
  • 2
    React Hooks实战：从useState到useContext深度解析
    113
  • 3
    销售利器大集结：13种智能销售工具全面解析
    325
  • 4
    【Uniapp 专栏】基于 Uniapp 的电商应用开发案例解析
    220
  • 5
    XML DOM 解析器
    62
  • 6
    构建高效AI系统：深度学习优化技术解析
    629
  • 7
    Java 8新特性之Lambda表达式与Stream API的深度解析
    107
  • 8
    深入解析Linux tee命令：从基础用法到高级场景的全面指南
    1439
  • 9
    PandasTA 源码解析（二十三）
    80
  • 10
    PandasTA 源码解析（二十二）（3）
    79

    • 相关课程

    更多
  • 第八届大学生创新创业大赛阿里命题IoT赛题解析
  • 云计算工程师解析与实战-网络专家篇（体验版）
  • 深入解析Docker容器化技术
  • Java面试疑难点解析 - 面试技巧及语言基础
  • Java面试疑难点解析 - Java Web开发
  • Java面试疑难点解析 - 系统架构及项目设计

    • 相关电子书

    更多
  • 神龙云服务器产品及技术深度解析
  • 弹性创造价值：基于ECS的最佳性价比实践解析
  • 又快又稳：阿里云下一代虚拟交换机解析

    • 相关实验场景

    更多
  • 通过云拨测对指定服务器进行Ping/DNS监测

    • 推荐镜像

    更多
  • DNS
  • NTP
  • wireshark
    • 下一篇
    阿里云无影云电脑免费试用，最长可试用3个月