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

innodb 锁分裂继承与迁移

简介: # innodb行锁简介 1. 行锁类型 ``` LOCK_S:共享锁 LOCK_X: 排他锁 ``` 2. GAP类型 ``` LOCK_GAP:只锁间隙 LOCK_REC_NO_GAP:只锁记录 LOCK_ORDINARY: 锁记录和记录之前的间隙 LOCK_INSERT_INTENTION: 插入意向锁,用于ins
+关注继续查看

innodb行锁简介

  1. 行锁类型
    LOCK_S:共享锁
    LOCK_X: 排他锁
  1. GAP类型
    LOCK_GAP:只锁间隙
    LOCK_REC_NO_GAP:只锁记录
    LOCK_ORDINARY: 锁记录和记录之前的间隙
    LOCK_INSERT_INTENTION: 插入意向锁,用于insert时检查锁冲突

每个行锁由锁类型和GAP类型组成
例如:
LOCK_X|LOCK_ORDINARY 表示对记录和记录之前的间隙加排他锁
LOCK_S|LOCK_GAP 表示只对记录前的间隙加共享锁

锁的兼容性:
值得注意的是,持有GAP的锁(LOCK_GAP和LOCK_ORDINARY)与其他非LOCK_INSERT_INTENTION的锁都是兼容的,也就是说,GAP锁就是为了防止插入的。

详细可以参考之前的月报

innodb 锁分裂、继承与迁移

这里的锁分裂和合并,只是针对innodb行锁而言的,而且一般只作用于GAP类型的锁。

  • 锁分裂

插入的记录的间隙存在GAP锁,此时此GAP需分裂为两个GAP

  lock_rec_inherit_to_gap_if_gap_lock:
  
  for (lock = lock_rec_get_first(block, heap_no);
        lock != NULL;
        lock = lock_rec_get_next(heap_no, lock)) {

           if (!lock_rec_get_insert_intention(lock)
               && (heap_no == PAGE_HEAP_NO_SUPREMUM
                   || !lock_rec_get_rec_not_gap(lock))) {

                   lock_rec_add_to_queue(
                           LOCK_REC | LOCK_GAP | lock_get_mode(lock),
                           block, heir_heap_no, lock->index,
                           lock->trx, FALSE);
           }
   }
  • 锁继承

删除的记录前存在GAP锁,此GAP锁会继承到要删除记录的下一条记录上

  lock_rec_inherit_to_gap:
  
  for (lock = lock_rec_get_first(block, heap_no);
     lock != NULL;
     lock = lock_rec_get_next(heap_no, lock)) {

        if (!lock_rec_get_insert_intention(lock)
            && !((srv_locks_unsafe_for_binlog
                  || lock->trx->isolation_level
                  <= TRX_ISO_READ_COMMITTED)
                 && lock_get_mode(lock) ==
                 (lock->trx->duplicates ? LOCK_S : LOCK_X))) {

                lock_rec_add_to_queue(
                        LOCK_REC | LOCK_GAP | lock_get_mode(lock),
                        heir_block, heir_heap_no, lock->index,
                        lock->trx, FALSE);
        }
}
  • 锁迁移

B数结构变化,锁信息也会随之迁移. 锁迁移过程中也涉及锁继承。

锁分裂示例

  • 锁分裂例子
set global tx_isolation='repeatable-read';

create table t1(c1 int primary key, c2 int unique) engine=innodb;
insert into t1 values(1,1);

begin;
# supremum 记录上加 LOCK_X|LOCK_GAP 锁住(1~)
select * from t1 where c2=2 for update;
# 发现插入(3,3)的间隙存在GAP锁,因此给(3,3)加LOCK_X|LOCK_GAP锁。这样依然锁住了(1~)
insert into t1 values(3,3);

这里如果插入(3,3)没有给(3,3)加LOCK_X|LOCK_GAP,那么其他连接插入(2,2)就可以成功

锁继承示例

  • 隔离级别repeatable-read
===== RR =====

set global tx_isolation='repeatable-read';
create table t1(c1 int primary key, c2 int unique) engine=innodb;
insert into t1 values(1,1),(2,2);


#会话信息


              session 1:             |              session 2:
begin;                               |
#(1,1) 加LOCK_X|LOCK_REC_NOT_GAP     |
delete from t1 where c1=1;           |
                                     |
                                     |     begin;
                                     |     # (1,1)加LOCK_X|LOCK_ORDINARY 等待
                                     |     select * from t1 where c1 <= 1  for update;
commit;                              |
                                     |     #(1,1)被删除,purge清理delete mark时,(1,1)上的锁继承到(2,2)上,锁为LOCK_X|LOCK_GAP
                                     |     #同时(1,1)上的锁都释放,session 2等待成功

验证:session 1执行insert into t1 values(1,1)发生了锁等待,说明(2,2)上有gap锁

mysql> select * from information_schema.innodb_locks;
+------------------------+-------------+-----------+-----------+-----------------+------------+------------+-----------+----------+-----------+
| lock_id                | lock_trx_id | lock_mode | lock_type | lock_table      | lock_index | lock_space | lock_page | lock_rec | lock_data |
+------------------------+-------------+-----------+-----------+-----------------+------------+------------+-----------+----------+-----------+
| 16582717714:888654:4:3 | 16582717714 | X,GAP     | RECORD    | `cleaneye`.`t1` | c2         |     888654 |         4 |        3 | 2         |
| 16582692183:888654:4:3 | 16582692183 | X,GAP     | RECORD    | `cleaneye`.`t1` | c2         |     888654 |         4 |        3 | 2         |
+------------------------+-------------+-----------+-----------+-----------------+------------+------------+-----------+----------+-----------+
2 rows in set (0.01 sec)
  其中session 2 在(2,2) 加了LOCK_X|LOCK_GAP
    session 1 在(2,2) 加了LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION. LOCK_INSERT_INTENTION与LOCK_GAP冲突发生等待
  • 隔离级别read-committed
===== RC =====
set global tx_isolation='read-committed';
 
drop table t1;
create table t1(c1 int primary key) engine=innodb;
insert into t1  values(1),(2);

#会话信息

           session 1                    |                  session 2
begin;                                  |
#(1) 加LOCK_X|LOCK_REC_NOT_GAP          |
delete from t1 where c1=1;              |
                                        |
                                        |           begin;
                                        |           #(1)加LOCK_S|LOCK_REC_NOT_GAP 等待                                    
                                        |           select *from t1 where c1 <=1 lock in share mode;
                                        |
COMMIT:                                 |
                                        |           #(1)被删除,purge清理delete mark时,(1)上的锁继承到(2)上,锁为LOCK_S|LOCK_GAP
                                        |           # 同时(1)上的锁都释放,session 2等待成功
                                        |       

验证
session 1执行insert into t1 values(1)发生了锁等待,说明(2)上有gap锁

mysql> select * from information_schema.innodb_locks;
+------------------------+-----------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| lock_id                | lock_trx_id     | lock_mode | lock_type | lock_table  | lock_index | lock_space | lock_page | lock_rec | lock_data |
+------------------------+-----------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| 1705:32:3:3            | 1705            | X,GAP     | RECORD    | `test`.`t1` | PRIMARY    |         32 |         3 |        3 | 2         |
| 421590768578232:32:3:3 | 421590768578232 | S,GAP     | RECORD    | `test`.`t1` | PRIMARY    |         32 |         3 |        3 | 2         |
+------------------------+-----------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
X.GAP insert 加锁LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION
S.GAP 加锁LOCK_S|LOCK_GAP,记录(2)从删除的记录(1)继承过来的GAP锁

而实际在读提交隔离级别上,insert into t1 values(1)应该可以插入成功,不需要等待的,这个锁是否继承值得商榷。

来看一个插入成功的例子

===== RC =====
set global tx_isolation='read-committed';
 
drop table t1;
create table t1(c1 int primary key) engine=innodb;
insert into t1  values(1),(2);

# 会话信息

           session 1                                        |                  session 2
                                                            |
                                                            |           begin;
                                                            |           #(1)加LOCK_S|LOCK_REC_NOT_GAP  
                                                            |           # 查询结果为(1,2)                                 
                                                            |           select *from t1 where c1 <=1 lock in share mode;
                                                            |           
begin;                                                      |
# 检查(1)上的锁与LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION       |
# 不冲突,插入成功                                            |          
insert into t1 values(0);                                   |           
                                                            |           #再次查询结果为(0,1,2)
commit;                                                     |           select *from t1 where c1 <=3 lock in share mode;
  • 隔离级别serializable
===== SERIALIZABLE =====

set global tx_isolation='SERIALIZABLE';
drop table t1;
create table t1(c1 int primary key) engine=innodb;
insert into t1  values(1),(2);

# 会话信息

               session 1:                  |                session 2:
begin;                                     |
#(1) 加LOCK_X|LOCK_REC_NOT_GAP             |
delete from t1 where c1=1;                 |
                                           |
                                           |         begin;
                                           |         #(1)上加LOCK_S|LOCK_ORDINARY 等待
                                           |         select *from t1 where c1 <=1 ;
                                           |
commit;                                    |
                                           |
                                           |         #(1)被删除,purge清理delete mark时,(1)上的锁继承到(2)上,锁为LOCK_S|LOCK_GAP
                                           |         # 同时(1)上的锁都释放,session 2等待成功
                                           |

验证方法同read-committed。

B树结构变化与锁迁移

B树节点发生分裂,合并,删除都会引发锁的变化。锁迁移的原则是,B数结构变化前后,锁住的范围保证不变。
我们通过例子来说明

  • 节点分裂

假设原节点A(infimum,1,3,supremum) 向右分裂为B(infimum,1,supremum), C(infimum,3,supremum)两个节点

infimum为节点中虚拟的最小记录,supremum为节点中虚拟的最大记录

假设原节点A上锁为3上LOCK_S|LOCK_ORIDNARY,supremum为LOCK_S|LOCK_GAP,实际锁住了(1~)
锁迁移过程大致为:

1)将3上的gap锁迁移到C节点3上

2)将A上supremum迁移继承到C的supremum上

3)将C上最小记录3的锁迁移继承到B的supremum上

迁移完成后锁的情况如下(lock_update_split_right)
B节点:suprmum LOCK_S|LOCK_GAP
C节点:3 LOCK_S|LOCK_ORINARY, suprmum LOCK_S|GAP

迁移后仍然锁住了范围(1~)

节点向左分裂情形类似

  • 节点合并

以上述节点分裂的逆操作来讲述合并过程
B(infimum,1,supremum), C(infimum,3,supremum)两个节点,向左合并为A节点(infimum,1,3,supremum)
其中B,C节点锁情况如下
B节点:suprmum LOCK_S|LOCK_GAP
C节点:3 LOCK_S|LOCK_ORINARY, suprmum LOCK_S|GAP

迁移流程如下(lock_update_merge_left):

1)将C节点锁记录3迁移到B节点

2)将B节点supremum迁移继承到A的supremum上

迁移后仍然锁住了范围(1~)

节点向右合并情形类似

  • 节点删除

如果删除节点存在左节点,则将删除节点符合条件的锁,迁移继承到左节点supremum上
否则将删除节点符合条件的锁,迁移继承到右节点最小用户记录上
参考lock_update_discard

锁继承相关的BUG

bug#73170 二级唯一索引失效。这个bug触发条件是删除的记录没有被purge, 锁还没有被继承的。如果锁继承了就不会出现问题。
bug#76927 同样是二级唯一索引失效。这个bug是锁继承机制出了问题。
以上两个bug详情参考这里

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

相关文章
挖坑,InnoDB的七种锁
本质上,这些都是InnoDB锁机制的问题。
541 0
Innodb MVCC
mvcc标准机制 多版本并发控制(Multiversion concurrency control)。 当对数据进行写操作时,不允许对被操作数据进行读操作,这样会导致数据库并发性能低下。于是用mvcc在并发访问(读或写)数据库时,对正在事务内处理的数据做多版本的管理,以降低写操作的堵塞而引发读操作的并发问题。
1715 0
一维条形码攻击技术(Badbarcode)
0x00 前言 在日常生活中,条形码随处可见,特别在超市,便利店,物流业,但你们扫的条形码真的安全吗?之前TK教主 在PacSec介绍的条形码攻击和twitter上的demo视频太炫酷,所以就自己买了个扫码器自己研究了一下 ,在研究时候也找遍了国内外所有资料,但是都没有对可以执行的攻击技术完整的文章,故有此文分享。
1305 0
local variable 'xxx' referenced before assignment
定义了一个全局变量 s ,Python的一个函数里面引用这个变量,并改变它的值, 结果报错local variable 'xxx' referenced before assignment, 代码如下: s = 2   def fun():        if s== 2:           print s         s= 3           错误的意思就是s这个变量在引用前还没有定义,这上面不是定义了么?但是后来我把s= 2这句去掉就好了。
4583 0
+关注
zysql
张远 MySQL/MyRocks
34
文章
10
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载