锁

读锁 / 共享锁

又称读锁（Shared Locks，S锁）。是针对同一份数据，多个读操作可以同时进行，不能写但可并行读

写锁 / 排他锁

又称写锁（Exclusive Locks，X锁）。针对写操作，假如当前写操作没有完成，那么它会阻断其它的写锁和读锁，即写加锁，其它读写都阻塞。

写锁比读锁有更高的优先级，一个写锁请求可能会被插入到读锁队列的前面，但是读锁不能插入到写锁前面。

读未提交 是没有加任何锁的，对于它来说没有隔离的效果，所以性能也是最好的

**串行 **加的是一把大锁，读的时候加共享锁，不能写；写的时候，加的是排它锁，阻塞其它事务的写入和读取，若是其它的事务长时间不能写入就会报超时

行锁，表锁和间隙锁，是从锁的粒度上进行划分的

行锁（Record Locks）

锁定当前数据行，锁的粒度小，加锁慢，发生锁冲突的概率小，并发度高

行锁也是 MyISAM 和 InnoDB 的区别之一，InnoDB 支持行锁并且支持事务

查询未命中索引时，会给所有行加锁，然后对不符合锁条件的行释放锁。

表锁

给整个表加锁，锁的粒度大，加锁快，开销小，但是锁冲突的概率大，并发度低

InnoDB 执行 DDL 时，会加表锁

区间锁

分为两种：Gap Locks 间隙锁和 Next-Key Locks 临键锁。就是开区间和闭区间的区别。一般通过 select for update 的语法实现

Gap Locks 会锁住两个索引之间的区间，比如 select * from User where id>3 and id<5 for update，就在区间 (3,5) 之间加锁

Next-Key Locks 是 Gap Locks + 行锁 形成闭区间锁，比如 select * from User where id>=3 and id=<5 for update，就在区间 [3,5] 之间加锁

间隙锁/临键锁只存在于 RR 级别下，因为它主要用于防止幻读，其他级别下不需要。

加上区间锁后，其他线程向该区间写入数据时会阻塞。

活锁

如果有多个事务 T1, T2, T3, T4... 不断锁数据 R，可能因为优先级不合理导致事务 T2 永远在等待，称为活锁。

避免活锁最简单的方法就是采用先进先出的策略。

死锁

事务 T1 锁了数据 R1，要锁 R2，同时 T2 锁了 R2，要锁 R1。两个事务都在等对方释放锁的情况，称为死锁。

死锁的预防

一次封锁法
- 一次封锁法要求每个事务必须一次性将所有要使用的数据全部加锁，否则就不能继续执行。
- 问题：
  - 扩大了锁范围，降低了并发度
  - 数据库中的数据是不断变化的，符合封锁条件的数据可能也会变，很难事先精确锁定范围
顺序封锁法
- 预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁
- 问题：
  - 和上面一样，数据是不断变化的，很难实现确定封锁对象，也就很难按规定顺序加锁

死锁的检测

超时法
- 事务等待时间超过配置则认为发生死锁
- 超时可能由其他原因引起，导致误判；若时限设太长，死锁发生后不能及时发现
等待图法
- 检查所有在一个锁上等待的事务是否已经成环；成环了说明出现死锁，根据一定的策略将某个事务回退将环切断而解除死锁
- innodb 采用的就是这个策略，死锁回滚时回滚持有行锁最少的事务

对事务型系统，死锁是无法避免的，所以程序在设计时必须考虑如何处理死锁。多数情况下只需要重新执行因死锁回滚的事务即可。

悲观锁

在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作。适用于同一数据竞争较严重的场景。

SELECT * FROM xxx WHERE id = 1 LOCK IN SHARE MODE;
SELECT * FROM xxx WHERE id = 1 FOR UPDATE;

乐观锁

指操作数据库时，想法很乐观，认为不会冲突，也不加锁。所以让线程不断去尝试更新，更新完检查影响行数。CAS 就是一种乐观锁的实现

乐观锁不是数据库自带的，需要我们自己去实现。如：

-- 这样如果status被别的线程修改，就不会更新成功
UPDATE xxx SET xxx WHERE id = ? AND status = 'A'

Last updated 1 year ago