概述

• MyISAM支持表锁,InnoDB支持表锁和行锁,默认为行锁

• 表级锁：开销小,加锁快,不会出现死锁.锁定粒度大,产生锁冲突的概率最高,并发量最低

• 行级锁：开销大,加锁慢,会出现死锁.锁力度小,产生锁冲突的概率小,并发度最高

MyISAM表级锁

锁模式

• show status like 'table%' 可以阐发锁争夺情况

• 表级锁分为两种模式：共享读锁,独有写锁

• 读读共享,读写互斥,写写互斥,写读互斥(好比写读互斥,当一个用户对user表进行写的时候,会阻塞其他用户的写操作和读操作)

加表锁

• 在select的时候自动加读锁,在update delete insert时,自动加写锁

• 一般不必要用户用lock table 命令直接显式加锁

显示加表锁时

• session1显示给user表加锁

  lock table user read;

• session1此时不克不及读取未锁定的class表,所以lock table时要一次性锁定要用到的表

• session1此时不克不及进行更新和插入,只能进行读取

• 其他session可以读取user表,然则更新会阻塞,而插入不会阻塞(可以通过设置concurrent_insert 系统变量来控制并发插入行为)

• 

锁调剂

• 当一个进程哀求user表的读锁,一个进程哀求user表的写锁,即使读哀求先到,也是哀求写锁成先成功

• 所以,MyISAM不适合年夜量的更新,因为年夜量更新会导致查操作很难获得读锁

InnoDB行级锁

行锁

• 通过 show status like 'InnoDB_row_lock' 来阐发行锁争夺情况

• 共享锁S：允许一个事务去读一行,阻止其他事务得到相同数据集的排他锁

• 排他锁X：允许得到排它锁的事务更新数据,阻止其他事务取得相同数据集的共享锁和排他锁

意向锁

• 所谓意向锁就是意图拿到锁,所以要获得共享锁时,必要先获得意向共享锁

• 意向共享所IS,一个事务给一个数据行加共享锁时,必需先获得表的IS锁

• 意向排它锁IX,一个事务给一个数据行加排他锁时,必需先获得该表的IX锁

间隙锁

• 范围查询时,好比select * from user where id>50 ,这个时候即使最大id为51,不仅会给符合条件的行加锁,也会给id大于51(不存在的记录)的加锁,这就是间隙锁

• 间隙锁办理了事务并发的幻读问题

兼容环境

加锁

• 意向锁是InnoDB自动加的

• 对付update insert delete 会自动加排它锁

• 对付select不会自动加锁

• Select * from user LOCK IN SHARE MODE 手动添加共享锁

• select * from user For update 手动添加排它锁

• 

行锁使用方式

• 通过索引条件检索数据时,才使用行锁,不然用表锁

• 也便是如果select的where列不是索引列,那么此时,实际上是给整个表加锁

• 检索条件是索引时,又分索引是凑集索引还是非凑集索引,如果是凑集索引(索引上叶节点存放的整条记录),在凑集索引上的加上行锁,而如果是非凑集索引,要在非凑集索引记录上加行锁,又要在凑集索引上加行锁

什么时候使用表锁

• 事务必要更新表的大部分数据.如果每一行都加上排他锁,锁冲突严重,那么此时执行效率低

• 事务涉及多个表,比拟复杂

死锁

MyISAM

• 由于加的是表锁,一次性锁定要必要的表,所以不会出现死锁

InnoDB

• 死锁一般是事务相互期待对方资源

• 产生死锁后,会自动检测,并让一个事务释放锁并回退

• 上面便是死锁的列子

乐观锁与消极锁

• 乐观锁和消极锁是一种思想,不是上面提到的数据库提供的锁,是并发控制的一种手段

• 有这样的场景,两个事务对商品(id=666)进行下单

乐观锁

• 有一个statu字段,未下单为0,下单为1

• 先查statu字段,下单进行更新, 再查询一次statu看是否与之前查的一样,一样的话commit,纷歧样的话rollback

• 实现方式：加一个版本号或者时间戳,提交前进行一次比拟

消极锁

• 直接对id为666的行加排他锁

• 实现方式：通过数据库的锁机制进行加锁

对照

• 消极锁比较谨慎,采用加锁机制,一定程度下降低了并发性

• 乐观锁认为一般情况下不会产生冲突,并发性较好

• 从冲突量和重试代价来衡量,如果冲突很少,或者重试代价不会很严重,那么通常情况下应该选择乐观锁,因为它能得到更好的并发性,而且更容易实现.但是,如果冲突的代价严重,那么就需要使用消极策略

两段锁原则

两段锁

• 是一个加锁原则,一种协议

• 锁操作分为两个阶段,加锁阶段只加锁不放锁,解锁阶段只放锁不加锁

• 好比一个事务中两个update语句,此时执行完第一个update不会立刻放锁,等加锁阶段完成后再进行放锁,也就是加锁和解锁不相交

• 事务开端后就处于加锁阶段,一直到执行ROLLBACK和COMMIT之前都是加锁阶段.ROLLBACK和COMMIT使事务进入解锁阶段,即在ROLLBACK和COMMIT模块中DBMS释放所有封锁.