不可能天天都是好日子,有了不顺心的日子,好日子才会闪闪发亮。
一、前言
对于行锁和表锁的含意区别,在面试中应该是高频呈现的,咱们应该对MySQL中的锁有一个零碎的意识,更具体的须要自行查阅材料,本篇为概括性的总结答复。
MySQL罕用引擎有MyISAM和InnoDB,而InnoDB是mysql默认的引擎。MyISAM不反对行锁,而InnoDB反对行锁和表锁。
如何加锁?
MyISAM在执行查问语句(SELECT)前,会主动给波及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会主动给波及的表加写锁,这个过程并不需要用户干涉,因而用户个别不须要间接用LOCK TABLE命令给MyISAM表显式加锁。
显式加锁:
上共享锁(读锁)的写法:lock in share mode,例如:
select math from zje where math>60 lock in share mode;
上排它锁(写锁)的写法:for update,例如:
select math from zje where math >60 for update;
二、表锁
不会呈现死锁,产生锁抵触几率高,并发低。
MyISAM引擎
MyISAM在执行查问语句(select)前,会主动给波及的所有表加读锁,在执行增删改操作前,会主动给波及的表加写锁。
MySQL的表级锁有两种模式:
表共享读锁
表独占写锁
读锁会阻塞写,写锁会阻塞读和写
对MyISAM表的读操作,不会阻塞其它过程对同一表的读申请,但会阻塞对同一表的写申请。只有当读锁开释后,才会执行其它过程的写操作。
对MyISAM表的写操作,会阻塞其它过程对同一表的读和写操作,只有当写锁开释后,才会执行其它过程的读写操作。
MyISAM不适宜做写为主表的引擎,因为写锁后,其它线程不能做任何操作,大量的更新会使查问很难失去锁,从而造成永远阻塞
三、行锁
会呈现死锁,产生锁抵触几率低,并发高。
在MySQL的InnoDB引擎反对行锁,与Oracle不同,MySQL的行锁是通过索引加载的,也就是说,行锁是加在索引响应的行上的,要是对应的SQL语句没有走索引,则会全表扫描,行锁则无奈实现,取而代之的是表锁,此时其它事务无奈对以后表进行更新或插入操作。
CREATE TABLE `user` (
`name` VARCHAR(32) DEFAULT NULL,
`count` INT(11) DEFAULT NULL,
`id` INT(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8
-- 这里,咱们建一个user表,主键为id
-- A通过主键执行插入操作,但事务未提交
update user set count=10 where id=1;
-- B在此时也执行更新操作
update user set count=10 where id=2;
-- 因为是通过主键选中的,为行级锁,A和B操作的不是同一行,B执行的操作是能够执行的
-- A通过name执行插入操作,但事务未提交
update user set count=10 where name='xxx';
-- B在此时也执行更新操作
update user set count=10 where id=2;
-- 因为是通过非主键或索引选中的,降级为为表级锁,
-- B则无奈对该表进行更新或插入操作,只有当A提交事务后,B才会胜利执行
for update
如果在一条select语句后加上for update,则查问到的数据会被加上一条排它锁,其它事务能够读取,但不能进行更新和插入操作
-- A用户对id=1的记录进行加锁
select * from user where id=1 for update;
-- B用户无奈对该记录进行操作
update user set count=10 where id=1;
-- A用户commit当前则B用户能够对该记录进行操作
行锁的实现须要留神:
行锁必须有索引能力实现,否则会主动锁全表,那么就不是行锁了。
两个事务不能锁同一个索引。
insert,delete,update在事务中都会主动默认加上排它锁。
行锁场景:
A用户生产,service层先查问该用户的账户余额,若余额足够,则进行后续的扣款操作;这种状况查问的时候应该对该记录进行加锁。
否则,B用户在A用户查问后生产前先一步将A用户账号上的钱转走,而此时A用户曾经进行了用户余额是否足够的判断,则可能会呈现余额曾经有余但却扣款胜利的状况。
为了防止此状况,须要在A用户操作该记录的时候进行for update加锁
扩大:间隙锁
当咱们用范畴条件而不是相等条件检索数据,并申请共享或排他锁时,InnoDB会给符合条件的已有数据记录的索引项加锁;对于键值在条件范畴内并不存在的记录,叫做间隙
InnoDB也会对这个”间隙”加锁,这种锁机制就是所谓的间隙锁
-- 用户A
update user set count=8 where id>2 and id<6
-- 用户B
update user set count=10 where id=5;
如果用户A在进行了上述操作后,事务还未提交,则B无奈对2~6之间的记录进行更新或插入记录,会阻塞,当A将事务提交后,B的更新操作会执行。
倡议:
尽可能让所有数据检索都通过索引来实现,防止无索引行锁降级为表锁
正当设计索引,尽量放大锁的范畴
尽可能减少索引条件,防止间隙锁
尽量管制事务大小,缩小锁定资源量和工夫长度