后端面经系列-明明有行锁，怎么突然就加了表锁

如无特殊说明，本文默认mysql使用的存储引擎是InnoDB。

什么是行锁、表锁？什么时候加表锁？怎么避免？ #

行锁，是指锁的粒度是行级别的，其锁定的记录是某个记录或者间隙（也可能是多个）。表锁是指锁的粒度是表级别的。

以下场景会添加表锁：

执行update、delete、insert语句执行时，innodb是不会加表锁的。有些地方会说执行update语句时，如果没用到索引，会转化为表锁，这不太准确，这种场景，如果是RR级别，会锁定所有扫描到记录和间隙，在效果上类似于表锁，但是不是表锁。

乐观锁，是指乐观的认为要更新的记录不会被修改，所以不加锁，而是在更新时判断记录是否被修改过。

一般是添加版本号字段（或者类似方式）。比如有一个版本号字段version，更新前该版本号是100，更新时在where条件中加上version=100这个条件。如果更新成功，version字段+1，。如果更新时version不是100，则影响的记录数是0。

IX、IS锁，是意向锁。其本身只是为了后续在加表级别的S锁和X锁时，判断表中是否有已经被加锁的记录，以避免用遍历的方式来查看表中有没有上锁的记录。
插入意向锁，在插入时，如果要插入的位置已经有间隙锁，则在等待时也需要再内存中生成锁结果，表明有实物想在这个间隙插入新记录，但是现在处于等待状态，这种类型的锁就是插入意向锁。

两阶段锁，是在锁在需要的时候被添加，但是要到事务结束的时候才被使用。

innodb会对扫描到的记录添加锁，如果是RR级别，即使扫描的记录不匹配，也会持有锁到事务结束。但是如果是RC级别的锁，如果扫描到的记录不匹配，则会释放锁。

RC级别下，在大多数场景中，不会有间隙锁和临键锁。但是如果是插入新记录时遇到唯一二级索引重复，都会对已经在B+树中的那条唯一二级索引记录添加next-key锁。

在RR级别下，InnoDB锁住了相关的索引记录和间隙，所以在插入新记录时，会被阻塞。就是说: 不会产生新的记录，在某种程度上可以说是解决了幻读问题。

唯一索引，添加锁时，如果是where是等值查询，则只会添加记录锁，不会添加间隙锁，如果是范围查询，则会添加记录锁和间隙锁。

遇到过更新语句死锁问题，使用到了索引合并，当时在搜索引擎上搜索，发现有类似案例，索引合并有可能会导致死锁。解决办法是修改索引，使其只使用到了一个索引。

我曾经遇到过场景，一条update语句，where语句不符合最左匹配原则，即没有索引中的第一个字段，导致出现慢SQL告警，更新语句长时间处于 Searching Rows For Update状态，即长时间在搜索要更新的记录。解决办法是修改语句，使其符合最左匹配原则。