开发者社区> xaubllxwtvaqiu> 正文

不可思议的一致性读场景

简介: 不可思议的一致性读场景
+关注继续查看

偶尔会被问到,老叶你上课是不是很简单,只要一份教材在手就可以反复讲很多年,甚至会问,你上课是不是只要照着念PPT就行?

我呸,都什么年代了,怎么还有这种想法。哪怕是在应试教育著称的中小学里,也是每个学期都要更新备课材料的,怎么可能一份教案讲一辈子,无非是中小学的课程内容变化没那么快。在以知识更新日新月异的IT行业,居然还有人抱着这种思想,简直了。

抱怨归抱怨,今天我要说一个在上课过程中被同学们问倒(是真的把我问倒了)的一个案例。

先交代下运行环境:

# MySQL版本:8.0.17 under MacOS
[root@yejr.me]>\s
mysql  Ver 8.0.17 for macos10.14 on x86_64 (MySQL Community Server - GPL)

Connection id:      19
...
Server version:     8.0.17 MySQL Community Server - GPL

# 事务隔离级别:RR
[root@yejr.me]> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+

# 测试表结构及数据
[root@yejr.me]> SHOW CREATE TABLE t1\G
**************** 1. row ****************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`), -- c1列是主键
  KEY `c2` (`c2`)  -- c2列是辅助索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[root@yejr.me]> select * from t1;
+----+------+------+
| c1 | c2   | c3   |
+----+------+------+
|  0 |    0 |    0 |
|  1 |    1 |    1 |
|  2 |    2 |    2 |
|  3 |    3 |    3 |
+----+------+------+

好,表演开始。

session1session2
begin;
#发起快照读
select * from t1 where c2=2;
...
2 | 2 | 2


begin;
#发起快照读
select * from t1 where c2=2;
...
2 | 2 | 2
#更新后立即提交事务
update t1 set c1=30 where c2=2;
commit;

select * from t1 where c2=2;
...
30 | 2 | 2


#再读一次,确认保持一致性
select * from t1 where c2=2;
...
2 | 2 | 2

#再来一次当前读
select * from t1 where c2=2 for update;
...
30 | 2 | 2

#恢复快照读
select * from t1 where c2=2;
...
2 | 2 | 2

#更新数据
update t1 set c1=c1+1 where c2=2;
...
Rows matched: 1 Changed: 1 Warnings: 0

#更新完毕后读取
select * from t1 where c2=2;
...
2 | 2 | 2
31 | 2 | 2
#神奇的一幕发生了,可以看到新旧两条记录

#提交事务后再读取
commit;
select * from t1 where c2=2;
...
31 | 2 | 2
#这次正常了,只能看到最新版本的数据

好,表演结束。相信看完后,你跟我的第一反应都是“握了个草,为毛会这样,这不科学”,可事实上的确如此,我再三测试了几次,都确认是这样的结果。后来我请教了下InnoDB核心开发者之一苏斌老师(苏斌老师之前在知数堂做过一次公开课分享,主题是 MySQL 8.0 InnoDB新特性)。一开始他也觉得这个案例不太可思议,后来经过查阅确认,认为这是符合一致性读的规则,看文档的解释:

A consistent read means that InnoDB uses multi-versioning to present to

a query a snapshot of the database at a point in time.

The query sees the changes made by transactions that committed before that
point of time, and no changes made by later or uncommitted transactions.

# 注意从这段开始的说明
The exception to this rule is that the query sees the changes made by earlier
statements within the same transaction.

This exception causes the following anomaly: If you update some rows in a
table, a SELECT sees the latest version of the updated rows, but it might
also see older versions of any rows.

If other sessions simultaneously update the same table, the anomaly means
that you might see the table in a state that never existed in the database.

简言之,上述文档说明了几点:

  1. InnoDB利用MVCC机制保证在事务范围内任意时间点的一致性读需求(也就是:RR级别下,在同一个事务内任意时间点的一致性读,总是能读取到同样的数据)
  2. RR级别下,是在发起第一个SELECT(不包含SELECT ... FOR UPDATE/FOR SHARE这种加锁读,以后另起一篇说这个事)时,创建的快照,因此能读取到在此之前已经提交的事务数据,在本事务之后修改的事务数据是看不到的
  3. 上述第2条规则的一个例外场景时,能读取到在本事务内自己修改的数据。因此当在事务内更新完一条记录后发起SELECT可以读取到更新后的数据,同时也可能读取到旧版本的数据

在本案例中,由于两个session都是直接更新主键列,又由于InnoDB引擎的特殊性,主键列会被选择作为聚集索引。对InnoDB主键的更新是不能inplace的,需要新创建一条记录。因此对主键索引的更新时,相当于此时同一条记录在表内有两个版本,一个是更新前(该版本后续会被删除),一个是更新后的,然后等待提交。在session2中,第一次SELECT后创建了一个快照版本 [2,2,2],而后的当前读可以读取到最新数据 [30,2,2],因为sesison1已经提交,不会被阻塞。而session2中的更新,会在当前读的基础上进行更新,所以更新后的版本是 [31,2,2],更新完毕后又再次进行一致性读,此时就可以看到新旧两个版本的数据了(因为旧版本对本事务而言,还在快照里)。本案例给我们的几点启示是

  1. 当你想更新一条记录时,最好一开始就对其先加锁(SELECT ... FOR UPDATE),而后再在事务中进行更新,这样就可以避免被其他session给更新了。虽然一开始就加锁可能会造成更多的锁等待和死锁概率,但为了数据一致性,也必须如此了。或者,可以把事务隔离级别降为RC,这样每次SELECT总能看到已提交的最新版本
  2. 永远”不要更新主键列
  3. 想要做到第2点,就需要让主键列“只用作主键”,不具备业务属性,也即是我们一直强调的一个开发规范“每个InnoDB表都要有一个自增整型列做主键,且该列没有业务用途

不知道我这样解释清楚了没有。InnoDB的这种做法,看起来像是合理的,但仔细想想又好像不太合理,我去提了个bug(#96205),但被拒了,囧...

Enjoy MySQL :)

            </div>

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
23534 0
阿里云服务器ECS远程登录用户名密码查询方法
阿里云服务器ECS远程连接登录输入用户名和密码,阿里云没有默认密码,如果购买时没设置需要先重置实例密码,Windows用户名是administrator,Linux账号是root,阿小云来详细说下阿里云服务器远程登录连接用户名和密码查询方法
22244 0
如何设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云安全组设置详细图文教程(收藏起来) 阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程。阿里云会要求客户设置安全组,如果不设置,阿里云会指定默认的安全组。那么,这个安全组是什么呢?顾名思义,就是为了服务器安全设置的。安全组其实就是一个虚拟的防火墙,可以让用户从端口、IP的维度来筛选对应服务器的访问者,从而形成一个云上的安全域。
18758 0
使用SSH远程登录阿里云ECS服务器
远程连接服务器以及配置环境
14696 0
阿里云服务器安全组设置内网互通的方法
虽然0.0.0.0/0使用非常方便,但是发现很多同学使用它来做内网互通,这是有安全风险的,实例有可能会在经典网络被内网IP访问到。下面介绍一下四种安全的内网互联设置方法。 购买前请先:领取阿里云幸运券,有很多优惠,可到下文中领取。
22023 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,云吞铺子总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系统盘、创建快照、配置安全组等操作如何登录ECS云服务器控制台? 1、先登录到阿里云ECS服务器控制台 2、点击顶部的“控制台” 3、通过左侧栏,切换到“云服务器ECS”即可,如下图所示 通过ECS控制台的远程连接来登录到云服务器 阿里云ECS云服务器自带远程连接功能,使用该功能可以登录到云服务器,简单且方便,如下图:点击“远程连接”,第一次连接会自动生成6位数字密码,输入密码即可登录到云服务器上。
36363 0
阿里云服务器ECS登录用户名是什么?系统不同默认账号也不同
阿里云服务器Windows系统默认用户名administrator,Linux镜像服务器用户名root
15444 0
1623
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载