表锁分为写锁,读锁,二者读读不阻塞,读写阻塞,写写阻塞
行锁分为共享锁,排他锁,即读锁和写锁
多粒度锁机制自动实现表、行锁共存,InnoDB内部有意向表锁
表锁:开销小,加锁快;不会出现死锁;锁定力度大,发生锁冲突概率高,并发度最低
行锁:开销大,加锁慢;会出现死锁;锁定粒度小,发生锁冲突的概率低,并发度高
锁的应用最终导致不同事务的隔离级别、而MVCC多版本并发控制,通过增加版本的形式实现两种隔离级别(不使用到锁),MVCC读写不阻塞,是行级锁的升级
隔离分为语句级Readcommitted隔离级别和事务级Repeatableread隔离级别
语句级:
事务A读取数据生成版本号
事务B修改数据(加了写锁)
事务A再读取数据时,是读取最新版本号的(若事务B提交了生成新版本号,没有提交则还是原来的版本号)
这里出现了不可重复读,事务A数据根据事务B而改变
事务级:
事务A读取数据生成版本号1
事务B修改数据生成新版本2
事务A再读取数据还是用版本号1
避免了不可重复读,出现了幻读
MySQL的 Repeatableread隔离级别加上GAP间隙锁解决了幻读,不需要串行了
丢失更新:一个事务的更新覆盖了其它事务的更新结果的解决方法:
乐观锁:要在表中设计一个版本字段。第一次要获取这个字段,处理完业务逻辑开始更新时,要对比现在的版本字段和第一次的版本字段是否相同,相同则更新反之拒绝。这里没有给数据库加锁,需要我们手动操作
UPDATE <表名> SET name="Howl",version=version+1 WHERE ID=#{id} AND version=#{version}
悲观锁:是数据库层面加锁,相当于排他锁,其他的事务就不能对它修改了,需要等待当前事务修改完之后才可以修改,在 select 语句后面加 FOR UPDATE
# 需要在事务中加,因为select是不加任何行锁的
SELECT * FROM <表名> FOR UPDATE / LOCK IN SHARE MODE
在范围查找时若请求写锁或读锁,InnoDB会给符合范围条件的已有数据的索引项加锁
对于键值在条件范围内但并不存在的记录,叫做间隙
间隙锁只会在Repeatableread及以下隔离级别使用,作用于防止幻读