Innodb 锁（简单笔记）

时间：2016-08-26 18:14:49 阅读：171 评论：0 收藏：0 [点我收藏+]

标签：

看过很多innodb锁的文章，已经明白的就不写了，简单做个笔记

Innodb 锁的兼容性：

1、意向锁和意向锁之间都是兼容的

2、X（排他锁）与任何锁都是不兼容的

3、排他意向锁 IX 于S锁是不兼容的

4、剩下的锁都是兼容的

三种锁

record lock

gap lock

next-key lock = record + gap

判断锁一定要加上隔离级别，不同级别锁的情况不同

对于Innodb 一般只需要考虑RR 和 RC 隔离级别即可

RR 三种锁

RC 可以认为只有record锁，但是当表存在唯一索引的时候是存在间隙锁（gap lock）只有这一种特殊情况

显示锁可以是S 或者 X锁

隐式锁只能是X锁

隐式锁的一种理解 begin insert into data 这时候如果没有提交事务，那么该记录应该是隐式锁，当你想要 select * from data for update 时候会锁等待，即等待这个隐式锁。

举例如下：

create table info ( id int primary key , name varchar(20)) engine = innodb;

session1 session 2

start transaction;

insert into info values (1,‘name‘);

select * from info where id = 1 for update;

session1 提交前都是等待隐式锁

commit;

隐式锁的个人理解就是某个激活的事务要更改一个索引值，这个值即将要改变，那么在另一个事务中要想以这个索引值为条件去更新数据，就需要等待，也就是要给这个被隐式锁锁住的索引加X锁，会LOCK_WAIT

书中有这么一段不是很理解：

drop table if exists a ;
create table a (
            a int primary key,
            b varchar(30)
            ) engine = innodb;
insert into values (1,‘a‘),(2,‘b‘),(3,‘c‘),(4,‘d‘);

两个会话事务：

A：
begin;
select * from a where a= 4 for update;
 
 
B:
begin;
select * from a where a <=2 lock in share mode;
delete from a where a = 3;
select * from a where a <=2 lock in share mode;

首先执行A，然后执行B中的前两句，当执行到B中第二个select的时候会发现锁等待了

书中解释：SELECT 游标锁定的最大记录被标记为操所是已经加锁成功的。其实导致这个现象的原因是SELECT游标锁定的最大记录被标记为了删除（未被真正PURGE删除），因此，当第二次再次执行select操作的时候，需要进一步锁定记录，也是a等于4的记录，而该记录已经在会话A中被锁定了。

不理解：

应该是A锁定a=4的记录，然后B的第一个select s锁锁定了a<=2的所有记录，delete 时候锁定了a=3的记录，但是delete的语句只是标记了a=3要删除，但是没有实际PURGE，第二个select 为什么要去锁定 a=4呢？

Innodb 锁（简单笔记）

标签：

原文地址：http://www.cnblogs.com/jiangwenju/p/5811281.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行

Innodb 锁 （简单笔记）

Innodb 锁（简单笔记）