开发者社区> xaubllxwtvaqiu> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

InnoDB这个将近20年的"bug"修复了

简介: InnoDB这个将近20年的"bug"修复了
+关注继续查看

0. 背景信息

1. MySQL 8.0.18 以前是怎么加锁的

2. MySQL 8.0.18 之后终于变天了


0. 背景信息

最近在课程中讲到InnoDB行锁时,讲到一个知识点

InnoDB行锁规则上,有这样的一个原则:


对有唯一属性的索引(主键/唯一索引)进行范围条件加锁时,

向右遍历(假设是普通正序索引,而且不加ORDER BY … DESC约束)过程中,

会一直扫描并加next-key锁到第一个不满足条件的记录为止,

但如果是RC级别,这个next-key lock会退化成gap lock,而RR下不会退化。


简言之,就是 "锁会被扩大化",从InnoDB引擎诞生以来一直都是如此。

其实严格来说,这个算是问题或缺陷,甚至也可以认为是bu

1. MySQL 8.0.18 以前是怎么加锁的

我们看看下面的案例。

首先,确认版本、隔离级别、表结构、索引以及数据。

建议:在PC端阅读本文体验更好。

# 5.6版本
[root@yejr.run]> select version();
+------------+
| version()  |
+------------+
| 5.6.39-log |
+------------+

#隔离级别
[root@yejr.run]> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+

#表数据
[root@yejr.run]> select * from t1;
+----+----+----+----+
| c1 | c2 | c3 | c4 |
+----+----+----+----+
|  0 |  0 |  0 |  0 |
|  1 |  1 |  1 |  0 |
|  3 |  3 |  3 |  0 |
|  4 |  2 |  2 |  0 |
+----+----+----+----+

#表结构&索引,c1是主键(有唯一属性),c2是辅助索引
[root@yejr.run]> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `c1` int(10) unsigned NOT NULL DEFAULT '0',
  `c2` int(10) unsigned NOT NULL DEFAULT '0',
  `c3` int(10) unsigned NOT NULL DEFAULT '0',
  `c4` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`c1`),
  KEY `c2` (`c2`)
) ENGINE=InnoDB;

下面的两个案例中,session2的请求会被阻塞

时间点session1sessioin2
T1begin;begin;
T2select * from t1 where c1<=1 for update;
T3
delete from t1 where c1=3;

被阻塞
时间点session1sessioin2
T1begin;begin;
T2
delete from t1 where c1=3;
T3select * from t1 where c1<=1 for update;

一样会被阻塞

原因在于 select * from t1 where c1<=1 for update 这个SQL中,除了对 c1<=1 的所有记录加上 LOCK_X|LOCK_ORDINARY(排他的next-key lock)之外,还需要对 c1=3 这条记录也加同样的锁

查看 information_schema 下的两个视图 innodb_locksinnodb_lock_waits 可以确认:

[root@yejr.run]> select * from INNODB_LOCKs\G

1. row **
lock_id: 2849:26:3:4 --请求的锁
lock_trx_id: 2849 --被阻塞的事务
lock_mode: X --拍他锁
lock_type: RECORD --锁类型是 LOCK_ORDINARY(即next-lock)
lock_table: `test`.`t1`
lock_index: PRIMARY
lock_space: 26
lock_page: 3
lock_rec: 4
lock_data: 3
2. row **
lock_id: 2848:26:3:4 --持有的锁
lock_trx_id: 2848 --持有锁的事务
lock_mode: X --排他锁 LOCK_X
lock_type: RECORD --锁类型是 LOCK_ORDINARY(即next-lock)
lock_table: `test`.`t1` --表
lock_index: PRIMARY --索引
lock_space: 26 --table space id
lock_page: 3 --page no
lock_rec: 4 --heap no
lock_data: 3 --被加锁的row data,即c1=3这条记录
2 rows in set (0.00 sec)

[root@yejr.run]> select * from INNODB_LOCK_waits\G
1. row **
requesting_trx_id: 2849 --请求锁的事务(被阻塞状态)
requested_lock_id: 2849:26:3:4 --请求的锁
blocking_trx_id: 2848 --持有锁的事务
blocking_lock_id: 2848:26:3:4 --持有的锁

当然了,也可以从 show engine innodb status\G 的结果中确认,这里不赘述。

2. MySQL 8.0.18 之后终于变天了

这个存在了将近20年的"bug",终于在2019.10.14发布的MySQL 8.0.18版本中被解决(修复)了,当时我居然没注意到这个release note。

InnoDB: An unnecessary next key lock was taken when performing 
a SELECT...FOR [SHARE|UPDATE] query with a WHERE condition that
specifies a range, causing one too many rows to be locked. The
most common occurrences of this issue have been addressed so
that only rows and gaps that intersect the searched range are
locked. (Bug #29508068)

简言之:就是不再需要对不必要的数据上锁啦。

再看看上面几个案例在最新的MySQL 8.0.19版本下的表现。

时间点session1sessioin2
T1begin;begin;
T2select * from t1 where c1<=1 for update;
T3
delete from t1 where c1=3;

不再被阻塞

看下加锁详情

select ENGINE_LOCK_ID,ENGINE_TRANSACTION_ID,THREAD_ID,OBJECT_NAME,INDEX_NAME,LOCK_TYPE,LOCK_MODE,LOCK_STATUS,LOCK_DATA from data_locks;
+-----------------------------------+-----------------------+-----------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
+-----------------------------------+-----------------------+-----------+-------------+------------+-----------+---------------+-------------+-----------+
| 4868124032:1127:140327172372248 | 18983 | 351 | t1 | NULL | TABLE | IX | GRANTED | NULL |
| 4868124032:44:4:4:140327176578584 | 18983 | 351 | t1 | PRIMARY | RECORD | X,REC_NOT_GAP | GRANTED | 3 |
| 4868123176:1127:140327172370216 | 18982 | 350 | t1 | NULL | TABLE | IX | GRANTED | NULL |
| 4868123176:44:4:2:140327176573976 | 18982 | 350 | t1 | PRIMARY | RECORD | X | GRANTED | 0 |
| 4868123176:44:4:3:140327176573976 | 18982 | 350 | t1 | PRIMARY | RECORD | X | GRANTED | 1 |
+-----------------------------------+-----------------------+-----------+-------------+------------+-----------+---------------+-------------+-----------+

可以看到,select * from t1 where c1<=1 for update; 这个SQL只会对 c1=[0,1] 两条记录加上 LOCK_X|LOCK_ORDINARY 锁,不会再对 c1=3 加锁了。

这个有年头的"bug"终于被搞定了,可喜可贺。

最后,来看下关于这个"bug"的描述。当然了,公开的bug系统看不到,需要用MOS账号才可以。下面是从代码git log里的部分摘抄:

commit d1b0afd75ee669f54b70794eb6dab6c121f1f179
Author: Jakub Łopuszański <jakub.lopuszanski@oracle.com>
Date: Wed Jul 17 16:34:01 2019 +0200

Bug #29508068 UNNECESSARY NEXT-KEY LOCK TAKEN

When doing a SELECT...FOR [SHARE|UPDATE] with a WHERE condition specifying a range,
we were locking "one row too much".
This patch fixes locking behaviour in several (hopefuly) most common cases, so that
we only lock rows and gaps which intersect the searched range.

- Added MTR to demonstrate current locking policy for end of range
- Got rid of goto
- Extracted logic of determining relation between range and row to separate function
- Extracted reoccuring patterns of modifications of search_tuple so it is easier to add same for stop_tuple
- Added prebuilt->m_stop_tuple and made sure it is in sync with prebuilt->m_mysql_handler->end_range for during read_range_first() and read_range_next()
- Added row_can_be_in_range field
- Do not lock the row (just the gap) if the row is same length and after the stop_tuple
- Do not lock the row (just the gap) if the row is same length and equal to stop_tuple and strict inequality was used for end of range
- Do not lock the row (just the gap) if the row is longer than stop_tuple and its prefix is after the stop_tuple
- Do not lock the row (just the gap) if the row is longer than stop_tuple and its prefix is equal to stop_tuple and strict inequality was used for end of range
- Do not lock the row nor gap if we already saw a row same length and equal to stop_tuple in previous iteration

Reviewed-by: Pawel Olchawa <pawel.olchawa@oracle.com>
RB:22293

所以,还是赶紧升级到MySQL 8.0的最新版本吧,不光功能更强,连锁也进一步优化了。

写到这里,不禁想嘚瑟一下,加入我的「MySQL优化课」课程优势就体现出来了,一旦有重大的知识更新,总是能比别人先一步知道,图便宜买一些万年不更新的旧课,甚至是盗版视频,都是享受不到这种快感的。

有点标题党,贻笑大方了。水平有限,理解有偏差的地方,还请不吝留言指正。

全文完。

            </div>

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

相关文章
InnoDB这个将近20年的"bug"修复了
InnoDB这个将近20年的"bug"修复了
12 0
InnoDB这个将近20年的"bug"修复了
InnoDB这个将近20年的"bug"修复了
14 0
程序员的bug修复宝典
程序员的bug修复宝典
74 0
dwz切换页数时bug修复过程
dwz切换页数时bug修复过程
32 0
bug修复---印象最深的OOM
项目中有一块图片列表展示功能,由于服务返回高清大图片偶尔会导致程序出现oom。为了彻底解决这个问题进行一次深度App优化。从原理诱因到解决问题进行深入研究。
70 0
修复过的一个bug
高并发的功能调用云产品时走过的路
82 0
duilib 修复CTreeViewUI控件动态添加子控件时,对是否显示判断不足的bug
转载请说明出处,谢谢~~:http://blog.csdn.net/zhuhongshu/article/details/42264947         这个bug我在仿酷狗开发日志里提到过,不过后来发现修复的不够好,后来重新修改了代码,并记录到博客。
1235 0
duilib 修复CTreeViewUI复选功能判断不准确的bug
转载请说明出处,谢谢~~:http://blog.csdn.net/zhuhongshu/article/details/42265209         CTreeViewUI里面自带了复选的功能,但是复选功能存在bug:       ...
849 0
7700
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载