【数据库事务锁的类型:读锁/写锁、悲观锁/乐观锁、表锁/页锁/行锁】
数据库事务锁的类型:读锁/写锁、悲观锁/乐观锁、表锁/页锁/行锁
- 一、读锁/写锁
- 1、锁定读
- 二、悲观锁/乐观锁
- 2.1 悲观锁
- 2.2 乐观锁
- 三、表锁/页锁/行锁
- 3.1 表级别的S锁、X锁
- 3.2 表级别的意向锁(intention lock)
一、读锁/写锁
对于数据库中并发事务的读-读场景不会引起什么问题,对于写-写、读-写或写-读这些场景可能会一起一些问题。
常见的可以分为2种锁:共享锁
(Shared Lock, s lock)和排他锁
(Exclusive Lock, x lock)。也叫读锁
(read lock)和写锁
(write lock)。
1、锁定读
- 对读取的记录加S锁:其他事务可以加读锁,要加写锁的话需要阻塞排队。
SELECT ... LOCK IN SHARE MODE;
# 或者
SELECT ... FOR SHARE. #(8.0新特性)
- 对读取的记录加X锁:其他事务加读锁和写锁都需要阻塞排队。
SELECT ... FOR UPDATE
二、悲观锁/乐观锁
从对待锁的态度上区分的话,可以分为悲观锁和乐观锁。
乐观锁
适合读操作多
的场景:优点是程序实现,不存在死锁问题
。悲观锁
适合写操作多
的场景:写操作多,使用乐观锁就不合适了。使用悲观锁,从数据库层面阻止其他事务对数据进行操作。
2.1 悲观锁
select…for update 语句执行过程中扫描过的行都会被加锁,因此在mysql中使用悲观锁,必须确定用上了索引,而不是全表扫描,否则会将整个表锁住。
SELECT ... FOR UPDATE
2.2 乐观锁
1、版本号机制
在表中设计一个版本字段:version。第一次读的时候获取当前版本值,更新的时候指定版本号(old_version_value)进行更新,只有当其他事务没有更新过时,这条语句才会更新成功。因此可以根据更新结果判断是否有其他事务修改过数据。
update ... set version=version+1
where version=old_version_value
2、时间戳机制
原理和版本号机制是一样的,只是说使用数据的更新时间来作为更新的指定条件。第一次查询得到数据的最新更新时间(update_time),更新的时候带着这个时间去进行更新,只有当其他事务没有更新过时,这条语句才会更新成功。
update ... set ...
where update_time=old_update_time
三、表锁/页锁/行锁
数据库系统需要在高并发响应
和系统性能
之间进行平衡,就产生了锁粒度
的概念。锁的粒度主要分为:表级锁、页级锁、行锁。
3.1 表级别的S锁、X锁
在对表执行SELECT、INSERT、DELETE、UPDATE这些DML语句时,Innodb不会添加表级别的S锁或X锁。而在对表执行ALTER TABLE、DROP TABLE这些DDL语句时,其他事务对这个表执行DML语句时会发生阻塞。这个过程是通过在server层使用一种称之为元数据锁(Metadata Lock)
结构来实现的。
一般情况下,不用手动使用到表级别的S锁和X锁:
LOCK TABLES t READ; # 手动加S锁
LOCK TABLES t WRITE; # 手动加X锁
3.2 表级别的意向锁(intention lock)
已经有一个表级别的S锁和X锁了,为什么还需要意向锁呢?
事务1对某行进行了修改,此时会对该行加一个行锁,同时会对该表加一个意向排他锁。此时事务2如果想对该表加一个表级别排他锁的话,发现已经有一个表级别意向排他锁了,此时就会阻塞。
而如果没有意向排他锁的话,事务2要对表加表级别的排他锁的话,数据库就需要对该表的每一页、每一行都查看是否有对应的页锁和行锁,这样太耗时了。
总结下:
- 意向锁的存在是为了协调行锁和表锁的关系,支持多粒度锁的共存。
- 意向锁是一种
不与行级锁冲突的表级锁
。
意向锁分为2种
- 意向共享锁(Intention Shared Lock, IS):
# 事务要获取某些行的S锁,必须先获取表的意向共享锁
SELECT ... FROM TABLE t ... LOCK IN SHARE MODE;
- 意向排他锁(Intention Exclusive Lock, IX):
# 事务要获取某些行的X锁,必须先获取表的意向排他锁
SELECT ... FROM TABLE t ... FOR UPDATE;
注意:意向锁之间是相互兼容的。但是意向锁和普通表级别的共享锁/排他锁不兼容,除了2个都是读的情况:即意向共享锁和表级别共享锁是兼容的。