网站图片太多百度指数查询app

一、读锁/写锁

对于数据库中并发事务的读-读场景不会引起什么问题，对于写-写、读-写或写-读这些场景可能会一起一些问题。

常见的可以分为2种锁：共享锁（Shared Lock, s lock）和排他锁（Exclusive Lock, x lock）。也叫读锁（read lock）和写锁（write lock）。

1、锁定读

1. 对读取的记录加S锁：其他事务可以加读锁，要加写锁的话需要阻塞排队。

SELECT ... LOCK IN SHARE MODE;
# 或者
SELECT ... FOR SHARE.  #(8.0新特性)

2. 对读取的记录加X锁：其他事务加读锁和写锁都需要阻塞排队。

SELECT ... FOR UPDATE 

二、悲观锁/乐观锁

从对待锁的态度上区分的话，可以分为悲观锁和乐观锁。

1. 乐观锁适合读操作多的场景：优点是程序实现，不存在死锁问题。
2. 悲观锁适合写操作多的场景：写操作多，使用乐观锁就不合适了。使用悲观锁，从数据库层面阻止其他事务对数据进行操作。

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要对表加表级别的排他锁的话，数据库就需要对该表的每一页、每一行都查看是否有对应的页锁和行锁，这样太耗时了。

总结下：

1. 意向锁的存在是为了协调行锁和表锁的关系，支持多粒度锁的共存。
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个都是读的情况：即意向共享锁和表级别共享锁是兼容的。