【MySQL】锁

一、并发事务访问相同记录的三种情况

并发问题的解决方案

锁定读时对读取记录加S锁

SELECT ... LOCK IN SHARE MODE;
#或者
SELECT ... FOR SHARE;

锁定读时对读取记录加X锁

SELECT ... FOR UPDATE;

锁粒度是由于数据库系统需要在高并发响应和系统性能两方面进行平衡所产生的概念。

该锁会锁定整张表，开销最小且避免了死锁，但是并发效率大打折扣。

表级别的S锁、X锁

在InnoDB上使用这些语句只会降低并发能力，所以一般不使用。

意向锁
在一个事务在设置行锁的时候其他事务就需要去遍历这张表的每行是否存在锁。所以通过在表上设置意向锁，从而避免其他事务的逐行检查。

SELECT column FROM table ... LOCK IN SHARE MODE;

SELECT column FROM table ... FOR UPDATE;

总的来说，意向锁是一种不与行锁冲突的表级锁，它是为了协调行锁和表锁的关系。支持多粒度的锁并存。

自增锁
自增锁时当向使用含有AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁。一个事务在持有自增锁的过程中，其他事务的插入语句都要被阻塞。

记录锁
记录锁仅仅把一条数据锁上，其分为S型记录锁和X型记录锁

间隙锁
在不可重复读的隔离级别下，MySQL可以采用加间隙锁的方式解决幻读问题。间隙锁仅仅是为了防止插入幻影记录而提出的。
请添加图片描述
如果在id=8的记录上加上间隙锁，那么在该事务提交之前不允许id在(3，8)之间的记录被插入。使用方法为：

SELECT * FROM student WHERE id=5 LOCK IN SHARE MODE;
# 或者
SELECT * FROM student WHERE id=5 FOR UPDATE;

因为表里没有id=5的记录，所以两条语句的间隙锁都加在id=8上，这里两条语句都是为了保护(3, 8)这个区间的间隙锁，这两条语句相互之间不会有冲突。

如果要对最前面的记录和最后面的记录加上间隙锁，则需要使用两条伪记录：

在这两条记录上设置间隙锁就可以达到不允许id小于1或者大于20的记录被插入。如果要在(20, + $\infty$ )上不允许记录插入，则需要

SELECT * FROM student WHERE id>20 LOCK IN SHARE MODE;

临键锁
临键锁本质是一个记录锁加间隙锁，相当于在间隙锁上加了一个等号。

SELECT * FROM student WHERE id <= 8 AND id > 3 FOR UPDATE;

插入意向锁
插入意向锁是由INSERT操作产生的一种间隙锁，是由于INSERT操作获取锁失败而开始等待产生的，是行级锁并不是表级锁。

页锁开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般。

悲观锁
悲观锁主要保证了数据的排他性，在事务查询数据的时候会认为该事务会修改数据从而上锁，从而影响阻塞别的事务。

SELECT ... FOR UPDATE是MySQL的悲观锁，它在执行过程中所有扫描的行都会被锁上，因此在MySQL中用悲观锁必须确定使用索引，而不是全表扫描，否则整个表都会被锁上。

悲观锁的不足在于其依靠数据库的锁机制来实现，对数据库性能开销较大。

乐观锁
乐观锁不采用数据库自身的锁机制，而是通过程序来实现。其适用于多读的应用类型来提高吞吐量。如果写操作过多则还是需要使用悲观锁。实现方式有版本号机制和CAS机制。

版本号机制
在表中设置版本字段version，第一次读的时候获取version字段，对数据进行更新和删除时，会执行UPDATE ... SET version=version+1 WHERE version=version。这就是通过对版本进行控制，从而避免了读写操作的相互干扰，即类似于git的思想。
时间戳机制
与版本号类似，把version换成了时间戳
CAS机制
java中的java.util.concurrent.atomic包下的原子变量类就是使用了乐观锁的CAS机制实现的。