目录
一、加锁机制
乐观锁与悲观锁是两种并发控制的思想,可用于解决丢失更新问题。
1、乐观锁
- 每次去取数据,都很乐观,觉得不会出现并发问题。
- 因此,访问、处理数据每次都不上锁。
- 但是在更新的时候,再根据版本号或时间戳判断是否有冲突,有则处理,无则提交事务。
2、悲观锁
- 每次去取数据,很悲观,都觉得会被别人修改,会有并发问题。
- 因此,访问、处理数据前就加排他锁。
- 在整个数据处理过程中锁定数据,事务提交或回滚后才释放锁
实例:会员续费,A会员到期,A想续费1个月,但是这个账号一直A的老婆在管理,A的老婆想续费3个月,如果 同时续费数据库又没有加锁那么会出现什么问题?会员+一个月还是+三个月
- SESSIONA A 先提交的情况
时间线 | SessionA | SessionB |
T1 | START TRANSACTION; | STATR TRANSACTION; |
T2 | SELECT * FROM user WHERE id=1; | SELECT * FROM user WHERE id=1; |
T3 | UPDATE user SET end_at=DATE_ADD(end_at,INTERVAL 1 MONTH),active_status=1 WHERE id=1; (Affected rows: 1) | |
T4 | COMMIT; | |
T5 | UPDATE user SET end_at=DATE_ADD(end_at,INTERVAL 1 MONTH),active_status=1 WHERE id=1; (Affected rows: 1) | |
T6 | COMMIT; |
- SESSIONA B 先提交的情况
时间线 | SessionA | SessionB |
T1 | START TRANSACTION; | STATR TRANSACTION; |
T2 | SELECT * FROM user WHERE id=1; | SELECT * FROM user WHERE id=1; |
T3 | UPDATE user SET end_at=DATE_ADD(end_at,INTERVAL 1 MONTH),active_status=1 WHERE id=1; (Affected rows: 1) | |
T4 | COMMIT; | |
T5 | UPDATE user SET end_at=DATE_ADD(end_at,INTERVAL 1 MONTH),active_status=1 WHERE id=1; (Affected rows: 1) | |
T6 | COMMIT; |
3、乐观锁实现
时间线 | SessionA | SessionB |
T1 | START TRANSACTION; | STATR TRANSACTION; |
T2 | SELECT * FROM user WHERE id=1; | SELECT * FROM user WHERE id=1; |
T3 | UPDATE user SET end_at = DATE_ADD(end_at,INTERVAL 1 MONTH),active_status = 1 WHERE id = 1 AND end_at = '日期'; ( Affected rows: 1) | |
T4 | COMMIT; | |
T5 | UPDATE user SET end_at = DATE_ADD(NOW(),INTERVAL 3 MONTH),active_status = 1 WHERE id = 1 AND end_at = '日期'; (Affected rows: 0) | |
T6 | ROLLBACK; -- 更加条件不成立,那么回滚 (或者程序去处理,再去执行事务还是回滚) |
以上乐观锁实现,一个更新成功COMMIT,一个失败回滚ROLLBACK,不会阻塞update和insert,实际上 没有加任何锁,只是在修改的时候多加条件限制(例如版本号或者时间)
4、悲观锁实现
时间线 | SessionA | SessionB |
T1 | START TRANSACTION; | STATR TRANSACTION; |
T2 | SELECT * FROM user WHERE id = 1 FOR UPDATE; -- 添加悲观锁 | |
T3 | UPDATE user SET end_at = DATE_ADD(NOW(),INTERVAL 1 MONTH),active_status = 1 WHERE id = 1; ( Affected rows: 1) | SELECT * FROM user WHERE id = 1 FOR UPDATE; -- 获取不了这一行的锁 |
T4 | COMMIT; | 阻塞到SESSION A 提交 |
T5 | SELECT * FROM user WHERE id = 1 FOR UPDATE; -- SESSION A 提交 才能 获取锁 | |
UPDATE user SET end_at = DATE_ADD(end_at,INTERVAL 3 MONTH),active_status = 1 WHERE id = 1; | ||
T6 | COMMIT; |
SELECT ..... WHERE id =1 FOR UPDATE ,
查询我们锁住这一行的数据,程序去判断,
如果是 end_at > now(),执行DATE_ADD(end_at,expr);
如果是 end_at < now(),执行DATE_ADD(now(),expr)
二、锁粒度
- 表锁: 开销小,加锁快;锁定力度大,发生锁冲突概率高,并发度最低;不会出现死锁。
- 行锁: 开销大,加锁慢;会出现死锁;锁定粒度小,发生锁冲突的概率低,并发度高。
- 页锁: 开销和加锁速度介于表锁和行锁之间;会出现死锁;锁定粒度介于表锁和行锁之间,并发度 一般
三、兼容性
1. 共享锁(shared lock,S锁)
-
也叫读锁(read lock)
- 一个事务获取了共享锁,其他事务可以获取共享锁,不能获取排他锁,其他事务可以进行读操作, 不能进行写操作。
- SELECT ... LOCK IN SHARE MODE 显式加共享锁。
2.排他锁(exclusive lock,X锁)
- 也叫写锁 (write lock)
- 如果事务T对数据A加上排他锁后,则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务 既能读数据,又能修改数据。
- SELECT ... FOR UPDATE 显式添加排他锁。
读锁 | 写锁 | |
读锁 | 兼容 | 冲突 |
写锁 | 冲突 | 冲突 |
LOCK TABLES [table1] READ,[table2] WRITE,[table3] WRITE; -- 锁表
LOCK TABLE `table` [READ|WRITE]; -- 解锁表
select column_name from tb_name WHERE condition FOR SHARE -- 行共享级锁,只有在执行事
务过程中才会有效
select column_name from tb_name WHERE condition FOR UPDATE -- 行排他锁
-- innodb 行锁是根据索引来的,如果没有索引那么将升级为表锁
LOCK TABLE tb_name READ,查询可以执行
LOCK TABLE tb_name WIRTE,阻塞所有读写
SELECT * FROM sys.`innodb_lock_waits`; -- 查询等待锁的语句
SELECT * FROM performance_schema.events_statements_history WHERE thread_id
IN(
SELECT b.`THREAD_ID` FROM sys.`innodb_lock_waits` AS a ,
performance_schema.threads AS b
WHERE a.`blocking_pid` = b.`PROCESSLIST_ID`)
ORDER BY timer_start ASC -- 查看持有锁的语句
四、锁模式
1、记录锁
在行相应的索引记录上的锁,锁定一个行记录. 它会在 id=1 的记录上加上记录锁,以阻止其他事务插入,更新,删除 id=1 这一行。
2、gap锁(间隙)
间隙锁是封锁索引记录中的间隔,或者第一条索引记录之前的范围,又或者最后一 条索引记录之后的范围。
3、next-key锁(临键锁)
是记录锁与间隙锁的组合,它的封锁范围,既包含索引记录,又包含索引区间。 MYSQL8 RR级别下默认使用临键锁.临键锁的主要目的,也是为了避免幻读(Phantom Read)。如果 把事务的隔离级别降级为RC,临键锁则也会失效。
4、意向锁
是为了支持多种粒度锁同时存在;
总结
- 记录锁、间隙锁、临键锁,都属于排它锁;
- 记录锁就是锁住一行记录;
- 间隙锁只有在事务隔离级别 RR 中才会产生;
- 唯一索引只有锁住多条记录或者一条不存在的记录的时候,才会产生间隙锁,指定给某条存在的记 录加锁的时候,只会加记录锁,不会产生间隙锁;
- 普通索引不管是锁住单条,还是多条记录,都会产生间隙锁;
- 间隙锁会封锁该条记录相邻两个键之间的空白区域,防止其它事务在这个区域内插入、修改、删除 数据,这是为了防止出现 幻读 现象;
- 普通索引的间隙,优先以普通索引排序,然后再根据主键索引排序(多普通索引情况还未研究);
- 事务级别是RC(读已提交)级别的话,间隙锁将会失效