看过很多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呢?