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

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

2017-11-22 1075
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
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实例
云解析DNS innodb
云解析DNS锁
innodb锁
科技小先锋
目录
相关文章
弹性计算小冉
|
7月前
|
存储 缓存 负载均衡
阿里云服务器实例选择指南：热门实例性能、适用场景解析对比参考
2025年，在阿里云的活动中，主售的云服务器实例规格除了轻量应用服务器之外，还有经济型e、通用算力型u1、计算型c8i、通用型g8i、计算型c7、计算型c8y、通用型g7、通用型g8y、内存型r7、内存型r8y等，以满足不同用户的需求。然而，面对众多实例规格，用户往往感到困惑，不知道如何选择。本文旨在全面解析阿里云服务器实例的各种类型，包括经济型、通用算力型、计算型、通用型和内存型等，以供参考和选择。
弹性计算小冉
400 2
弹性计算小冉
|
7月前
|
存储 机器学习/深度学习 人工智能
阿里云服务器第八代通用型g8i实例评测：性能与适用场景解析
阿里云服务器通用型g8i实例怎么样？g8i实例采用CIPU+飞天技术架构，并搭载最新的Intel 第五代至强可扩展处理器（代号EMR），不仅性能得到大幅提升，同时还拥有AMX加持的AI能力增强，以及全球范围内率先支持的TDX机密虚拟机能力。这些特性使得g8i实例在AI增强和全面安全防护两大方面表现出色，尤其适用于在线音视频及AI相关应用。本文将深入探讨g8i实例的产品特性、优势、适用场景及规格族，以帮助您更好地了解这款产品，以供参考和选择。
弹性计算小冉
263 2
弹性计算小冉
|
9月前
|
存储 运维 资源调度
阿里云服务器经济型e实例解析：性能、稳定性与兼顾成本
阿里云经济型e云服务器以其高性价比、稳定可靠的性能以及灵活多样的配置选项，成为了众多企业在搭建官网时的首选。那么，阿里云经济型e云服务器究竟怎么样？它是否能够满足企业官网的搭建需求？本文将从性能表现、稳定性与可靠性、成本考虑等多个方面对阿里云经济型e云服务器进行深入剖析，以供大家参考选择。
弹性计算小冉
565 37
潜意识Java
|
9月前
|
存储 Java 计算机视觉
Java二维数组的使用技巧与实例解析
本文详细介绍了Java中二维数组的使用方法
潜意识Java
277 15
那年春天
|
11月前
|
存储 负载均衡 监控
数据库多实例的深入解析
【10月更文挑战第24天】数据库多实例是一种重要的数据库架构方式，它为数据库的高效运行和灵活管理提供了多种优势。在实际应用中，需要根据具体的业务需求和技术环境，合理选择和配置多实例，以充分发挥其优势，提高数据库系统的性能和可靠性。随着技术的不断发展和进步，数据库多实例技术也将不断完善和创新，为数据库管理带来更多的可能性和便利。
那年春天
407 57
bruce_xiaowei
|
10月前
|
数据挖掘 vr&ar C++
让UE自动运行Python脚本：实现与实例解析
本文介绍如何配置Unreal Engine（UE）以自动运行Python脚本，提高开发效率。通过安装Python、配置UE环境及使用第三方插件，实现Python与UE的集成。结合蓝图和C++示例，展示自动化任务处理、关卡生成及数据分析等应用场景。
bruce_xiaowei
971 5
LuckiBit
|
10月前
|
存储 网络协议 算法
【C语言】进制转换无难事：二进制、十进制、八进制与十六进制的全解析与实例
进制转换是计算机编程中常见的操作。在C语言中，了解如何在不同进制之间转换数据对于处理和显示数据非常重要。本文将详细介绍如何在二进制、十进制、八进制和十六进制之间进行转换。
LuckiBit
1232 5
弹性计算小冉
|
11月前
|
存储 机器学习/深度学习 编解码
阿里云服务器计算型c8i实例解析：实例规格性能及使用场景和最新价格参考
计算型c8i实例作为阿里云服务器家族中的重要成员，以其卓越的计算性能、稳定的算力输出、强劲的I/O引擎以及芯片级的安全加固，广泛适用于机器学习推理、数据分析、批量计算、视频编码、游戏服务器前端、高性能科学和工程应用以及Web前端服务器等多种场景。本文将全面介绍阿里云服务器计算型c8i实例，从规格族特性、适用场景、详细规格指标、性能优势、实际应用案例，到最新的活动价格，以供大家参考。
弹性计算小冉
304 2
游客44yag4ft7nckq
|
12月前
|
XML 数据格式
HTML 实例解析
本文介绍了HTML中常见元素的使用方法，包括`<p>`、`<body>`和`<html>`等。详细解析了这些元素的结构和作用，并强调了正确使用结束标签的重要性。此外，还提到了空元素的使用及大小写标签的规范。
游客44yag4ft7nckq
91 1
bruce_xiaowei
|
数据可视化 Python
Python绘制基频曲线——实例解析与应用探讨
Python绘制基频曲线——实例解析与应用探讨
bruce_xiaowei
101 0

热门文章

最新文章

  • 1
    介绍MySQL的InnoDB引擎特性
  • 2
    DNS更新后不生效？快速排查攻略
  • 3
    MySQL · 引擎特性 · InnoDB 大字段压缩
  • 4
    MySQL · 引擎特性 · InnoDB redo log漫游
  • 5
    MySQL Innodb Purge简介
  • 6
    Innodb:RR隔离级别下insert...select 对select表加锁模型和死锁案列
  • 7
    MySQL5.5索引数在InnoDB引擎内与索引数在mysql中定义的数量是不一致问题
  • 8
    4种事务的隔离级别，InnoDB如何巧妙实现？
  • 9
    MySQL第二讲：MySQL innoDB存储引擎中索引原理
  • 10
    ​innodb存储引擎优化
  • 1
    DNS更新后不生效？快速排查攻略
    253
  • 2
    2025云栖大会分论坛《共建韧性互联网基础资源服务（DNS+IPv6）》即将开幕，欢迎光临
    91
  • 3
    阿里云上云流程参考：云服务器+域名+备案+域名解析绑定，全流程图文详解
    516
  • 4
    阿里云【域名解析】图文详细流程（步骤详细小白也能搞定）
    2413
  • 5
    利用Private Zone DNS - 搭建AD但不搭建DNS服务器如何加域
    96
  • 6
    DNS+：互联网的下一个十年，为什么域名系统正在重新定义数字生态？ ——解读《“DNS+”发展白皮书（2023）》
    333
  • 7
    SSL证书验证全攻略：DNS/HTTP/手动解析怎么选？
    674
  • 8
    Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
    168
  • 9
    使用nps配置内网穿透加域名解析
    692
  • 10
    阿里云服务器国际站dns服务器不可用怎么办?dns可以随便改吗?
    1619

    • 相关课程

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

    • 相关电子书

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

    • 推荐镜像

    更多
  • DNS
    • 下一篇
    阿里云oss简介和如何对接使用