Consistent Nonlocking Reads,Locking Reads 和Phantom Rows

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 以Consistent Nonlocking Reads,Locking Reads为突破点,用简单的例子来说明mysql常用的事务隔离级别(READ COMMITTED, REPEATABLE READ)和lock(record lock,gap lock,next-key lock, Insert Intention Lock)的关系

作者:手辨

实为吾之愚见,望诸君酌之!闻过则喜,与君共勉

初衷是想用简单说下innodb的Transaction Isolation Levels和InnoDB Locking之间的关系,因为只写的话不容易理解,后来想以Consistent Nonlocking Reads,Locking Reads为突破点,用简单的例子来说明mysql常用的事务隔离级别(READ COMMITTED, REPEATABLE READ)和lock(record lock,gap lock,next-key lock, Insert Intention Lock)的关系,所以看起来更像是围绕mysql的三种select的测试,下面的测试多基于自建mysql进行

第一节 测试数据

create table MOCK_DATA (

         id INT auto_increment,

         first_name VARCHAR(50),

         last_name VARCHAR(50),

         email VARCHAR(50),

         ram_num INT,

         ip_address VARCHAR(20),

         primary key(id)

);

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (1, 'Emelen', 'Jayme', 'ejayme0@adobe.com', 16, '212.117.129.58');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (2, 'Gaston', 'Rosenwald', 'grosenwald1@woothemes.com', 1, '177.160.142.3');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (3, 'Onida', 'Beckey', 'obeckey2@bluehost.com', 100, '246.91.205.135');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (4, 'Pen', 'Schwant', 'pschwant3@wikimedia.org', 70, '173.23.34.192');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (5, 'Amelina', 'Yousef', 'ayousef4@zimbio.com', 36, '236.121.250.36');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (6, 'Sallie', 'Gentner', 'sgentner5@bluehost.com', 21, '195.38.73.120');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (7, 'Julienne', 'Dobrovolski', 'jdobrovolski6@hostgator.com', 74, '123.70.179.160');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (8, 'Idelle', 'O''Shiel', 'ioshiel7@naver.com', 62, '16.85.248.74');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (9, 'Earle', 'Giacomazzo', 'egiacomazzo8@hibu.com', 49, '108.191.110.142');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (10, 'Celestyn', 'Wyrill', 'cwyrill9@prnewswire.com', 4, '82.232.65.146');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (11, 'Bryanty', 'Broadbridge', 'bbroadbridgea@nih.gov', 7, '117.70.48.113');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (12, 'Tybi', 'Pegden', 'tpegdenb@home.pl', 96, '138.137.28.35');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (13, 'Wash', 'Leed', 'wleedc@cnn.com', 64, '21.106.123.29');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (14, 'Rog', 'Muncer', 'rmuncerd@blogger.com', 49, '161.38.63.134');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (15, 'Alec', 'Borleace', 'aborleacee@ustream.tv', 71, '152.192.32.148');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (16, 'Roberto', 'Seer', 'rseerf@ocn.ne.jp', 94, '238.104.254.189');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (17, 'Brittani', 'Ivers', 'biversg@hubpages.com', 62, '219.48.22.242');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (18, 'Jenna', 'Weekly', 'jweeklyh@google.co.uk', 33, '0.94.96.82');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (19, 'Rog', 'Wabersich', 'rwabersichi@house.gov', 53, '151.65.81.105');

insert into MOCK_DATA (id, first_name, last_name, email, ram_num, ip_address) values (20, 'Elihu', 'Trowsdall', 'etrowsdallj@123-reg.co.uk', 72, '181.39.19.158');

第二节 现象对比

Session1:

开启session1,执行一次select:

image.png

Session2:

开启session2,插入一条数据

image.png

Session 3:

再次执行select,同时再执行select…lock in share mode和select…for update

image.png

第三节 Consistent Nonlocking Reads:Select

3.1 加锁测试

3.1.1 REPEATABLE READ

Session1:

image.png

Session2执行show engine innodb statusG:

image.png

如上可见,在REPEATABLE READ的隔离级别下mysql执行select这类操作的时候,是不加锁的,并且会生成一个read view来判断可见性

3.1.2 READ COMMITTED

Session1:

image.png

Session2执行show engine innodb statusG:

image.png

如上可见,在READ COMMITTED的隔离级别下mysql执行select这类操作的时候,是不加锁的,不会生成一个read view来判断可见性

3.2 REPEATABLE READ测试

3.2.1 REPEATABLE READ

Session1:

image.png

Session2:

image.png

Session1:

image.png

如上可见,在REPEATABLE READ的隔离级别下,可以实现REPEATABLE READ

3.2.2 READ COMMITTED
Session1:

image.png

Session2:

image.png

Session1:

image.png

如上可见,在READ COMMITTED的隔离级别下,不能保证REPEATABLE READ

3.3 Phantom Rows测试

3.3.1 REPEATABLE READ

Session1:

image.png

Session2:

image.png

Session1:

image.png

如上可见,在REPEATABLE READ的隔离级别下,可以避免出现简单的Phantom Rows

例外如下:

image.png

3.3.2 READ COMMITTED

Session1:

image.png

Session2:

image.png

Session1:

image.png

如上可见,在READ COMMITTED的隔离级别下无法避免Phantom Rows

第四节 Locking Reads :SELECT ... LOCK IN SHARE MODE/FOR UPDATA

此处以测试lock in share mode为例

4.1加锁测试

4.1.1 REPEATABLE READ

Session1:

image.png

Session2执行show engine innodb statusG:

image.png

如上可见,在REPEATABLE READ的隔离级别下mysql执行select…lock in share mode这类操作的时候,是加锁的,没有read view

4.1.2 READ COMMITTED

Session1:

image.png

Session2执行show engine innodb statusG:

image.png

如上可见,在READ COMMITTED的隔离级别下mysql执行select…lock in share mode这类操作的时候,是加锁的,不会生成一个read view来判断可见性

4.2 REPEATABLE READ测试

4.2.1 REPEATABLE READ

Session1:

image.png

Session2:

image.png

Session3执行show engine innodb statusG:

image.png

如上可见,在REPEATABLE READ的隔离级别下,一些情况下select…lock in shared mode(S lock)会阻塞住update(X lock)操作(同一个主键id),可以REPEATABLE READ

4.2.2 READ COMMITTED

Session1:

image.png

Session2:

image.png

Session3执行show engine innodb statusG:

image.png

如上可见,在READ COMMITTED的隔离级别下,一些情况下select…lock in shared mode(S lock)会阻塞住update(X lock)操作(同一个主键id)

4.3 Phantom Rows测试

4.3.1 REPEATABLE READ

Session1:

image.png

Session2:

image.png

Session3执行show engine innodb statusG:

image.png

如上可见,在REPEATABLE READ的隔离级别下, 一些情况下select…lock in shared mode(gap lock+S lock)会阻塞住insert(X lock)操作,防止幻读

4.3.2 READ COMMITTED

Session1:

image.png

Session2:

image.png

Session1:

image.png

如上可见,在READ COMMITTED的隔离级别下无法避免Phantom Rows

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
25天前
MVCC是什么
MVCC是多版本并发控制,为每次事务生成一个新版本数据,每个事务都有自己的版本,从而不加锁就拒绝读写冲突,这种读叫做快照读。只在读已提交和可重复读中生效。 实现原理由四个东西保证,他们是: undolog日志:记录了数据历史版本 readView:事务进行快照读时产生的视图,记录了当前系统中活跃的事务id,控制哪个历史版本对当前事务可见 隐藏字段DB_TRC_ID: 最近修改记录的事务ID 隐藏字段DB_Roll_PTR: 回滚指针,配合undolog指向数据的上一个版本
2.4 Scattering Reads
2.4 Scattering Reads
54 0
2.5 Gathering Writes
2.5 Gathering Writes
72 0
|
存储 缓存 分布式计算
译|Eventually Consistent
译|Eventually Consistent
57 0
|
关系型数据库 MySQL 数据库
简单聊聊MVCC
本文章仅仅是从一个点来讲MVCC,比较粗浅,并不能代表这就是全部的MVCC。网上还有许多其他详细的MVCC介绍文章,可以结合起来阅读。
简单聊聊MVCC
|
关系型数据库 MySQL 数据库
什么是 MVCC
上一篇文章我们说到数据库的四种事务隔离级别,可以通过加锁的方式来实现,只是效率太低,事实上,MySQL 是通过 MVCC(多版本并发控制)来实现的。 具体原理有一点点复杂,需要你用点心才能看懂,今天我们就以「可重复读隔离级别」为例来详细说明其具体原理。
196 0
什么是 MVCC
|
关系型数据库 MySQL 测试技术
Consistent Nonlocking Reads,Locking Reads 和Phantom Rows
初衷是想用简单说下innodb的Transaction Isolation Levels和InnoDB Locking之间的关系,因为只写的话不容易理解,后来想以Consistent Nonlocking Reads,Locking Reads为突破点,用简单的例子来说明mysql常用的事务隔离级别.
3164 0