[转]MySQL中乐观锁、悲观锁(共享锁、排他锁)简介

时间:2022-10-01 08:55:07

InnoDB与MyISAM

Mysql 在5.5之前默认使用 MyISAM 存储引擎,之后使用 InnoDB。 
MyISAM 操作数据都是使用的表锁,你更新一条记录就要锁整个表,导致性能较低,并发不高。当然同时它也不会存在死锁问题。 
而 InnoDB与MyISAM 的最大不同有两点:一是 InnoDB支持事务;二是 InnoDB采用了行级锁。 
在 Mysql 中,行级锁并不是直接锁记录,而是锁索引。索引分为主键索引和非主键索引两种,如果一条sql 语句操作了主键索引,Mysql 就会锁定这条主键索引;如果一条语句操作了非主键索引,MySQL会先锁定该非主键索引,再锁定相关的主键索引。如果不通过索引条件检索数据,那么InnoDB将对表中所有数据加锁,实际效果跟表锁一样。

乐观锁与悲观锁

乐观锁:总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁,但是在更新时会判断其他线程在这之前有没有对数据进行修改,一般会使用版本号机制或CAS操作实现。 
version方式:一般是在数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。 
核心SQL代码: 
update table set x=x+1, version=version+1 where id=#{id} and version=#{version}; 
CAS操作方式:即compare and swap 或者 compare and set,涉及到三个操作数,数据所在的内存值,预期值,新值。当需要更新时,判断当前内存值与之前取到的值是否相等,若相等,则用新值更新,若失败则重试,一般情况下是一个自旋操作,即不断的重试。 
乐观锁一般乐观锁只用在高并发、多读少写的场景。

悲观锁: 总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等),当其他线程想要访问数据时,都需要阻塞挂起。可以依靠数据库实现,如行锁、读锁和写锁等,都是在操作之前加锁。共享锁、排它锁都是悲观锁。 一旦通过悲观锁锁定一个资源,那么其他需要操作该资源的使用方,只能等待直到锁被释放,好处在于可以减少并发,但是当并发量非常大的时候,由于锁消耗资源,并且可能锁定时间过长,容易导致系统性能下降,资源消耗严重。因此一般我们可以在并发量不是很大,并且出现并发情况导致的异常用户和系统都很难以接受的情况下,会选择悲观锁进行。

共享锁与排他锁

数据库的增删改操作默认都会加排他锁,而查询不会加任何锁。 
共享锁(读锁):对某一资源加共享锁,自身可以读该资源,其他人也可以读该资源(也可以再继续加共享锁,即 共享锁可多个共存),但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为: 
select * from table lock in share mode 
排他锁(写锁):对某一资源加排他锁,自身可以进行增删改查,其他人无法进行任何操作。语法为: 
select * from table for update –增删改自动加了排他锁

另外,对于获取共享锁后执行更新操作,可能会引起死锁。如事务A申请了行X的共享锁,事务B接着也申请了行X的共享锁,这时事务A要对行X进行更新操作,那么就需要等待行X上其他事务释放共享锁后获取排他锁,但事务B也要执行更新操作,这时便产生死锁(参考深入浅出MYSQL - InnoDB的行锁模式及加锁方法):
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
所以如果需要执行更新操作,应该直接申请获取排他锁,而不是共享锁。

参考文章:https://blog.csdn.net/weixin_43152242/article/details/82501403