数据库锁

锁分类

--按对数据的操作粒度分为：

1） 表锁：以表为单位锁定。加锁开销小；发生锁冲突的概率高,并发度低；不会出现死锁

2） 行锁：以行为单位锁定。加锁开销大；发生锁冲突的概率低,并发度高；会出现死锁

--按对数据的操作类型分：

1） 读锁（共享锁S）：若当前session对某行或表加了读锁。其它session依旧可以获取到该行或表的读锁，进行查询操作；其它session无法获取到该行或表的写锁。需要获取该行或表的写锁的操作将会被阻塞。

2） 写锁（排它锁X）：若当前session对某行或表加了写锁，则该行或表的读锁和写锁都将无法被其它session获取到。需要获取该行或表的读锁或写锁的操作都将被阻塞。

 

MyISAM的锁机制：

MyISAM 在执行SELECT前，会自动给涉及到的所有表加读锁，并在执行完select语句后解除所加的锁；在执行UPDATE、DELETE、INSERT前，会自动给涉及到的所有表加写锁，并在执行完相应语句后解除所加的锁。

 

InnoDB的锁机制：

InnoDB在执行SELECT前，不会加任何锁；在执行UPDATE、DELETE和INSERT语句前，若走的是索引，则会给索引锁涉及到的行加写锁；若没走索引，则行级写锁将会升级为表级写锁。在commit/rollback后解除所加的锁。

（显式加行级读锁：...in share mode;  显式加行级写锁：...for update）

 

意向共享锁：当InnoDB要为某行加行级共享锁前，会首先去为该行所属的表加上表级的意向共享锁，以此来标记该表中已被加了行级共享锁，从而阻止表级写锁的上锁。

意向排他锁：当InnoDB要为某行加行级排他锁前，会首先去为该行所属的表加上表级的意向排他锁，以此来标记该表中已被加了行级排他锁，从而阻止表级读锁和表级写锁的上锁。

 

行锁

 

记录锁（Record Lock）：当加锁（读锁或写锁）的对象，是已存在于表中的某些行，此时添加的为记录锁。如select * from t where id=1 or id=4 in share mode; update t set value=1 where id=1 or id=4; delete from t where id=1 or id=4。记录锁只会锁定指定的那些行，这里锁定了id为1和id为4的行。

间隙锁（Gap Lock）：当加锁（读锁或写锁）的对象，是不存在于表中的某些行，此时添加的为间隙锁。如select * from t where id=2 or id=8 in share mode。间隙锁将会锁定间隙中的所有不存在主键，这里将会锁定主键1和4之间的间隙以及主键7和10之间的间隙，即id=2,3,8,9（由此可见，行锁锁的实际不是某个具体的行，而是锁的主键）。此时，对主键为2,3,8,9的增删改查操作，都将被阻塞。

临键锁（Next-key Lock）：当加锁（读锁或写锁）的对象，一部分是已存在于表中的某些行一部分是不存在于表中的行，此时添加的是临键锁。如select * from t where id>2 and id<6 in share mode，该语句相当于...where or id=3 or id=4 or id=5...。临键锁将会锁定间隙中的所有不存在的主键以及间隙右边的已存在主键。这里将会锁定id=2,3,4,5,6,7

 

InnoDB在repeatable read隔离级别下，解决幻读问题的机制：

--在快照读（普通select）中，InnoDB依靠MVCC的一致性视图解决了幻读问题。因为每次读取的都是相同的视图，选出的一定是相同的数据，从而解决了幻读问题。

--在当前读（in share mode）中，InnoDB依靠记录锁、间隙锁、临键锁解决了幻读问题。当对某个范围的数据进行读取时，InnoDB会锁住该范围的全部已存在和未存在的记录，从而使得这个范围内无法插入任何记录，解决了幻读问题。