MySQL——InnoDB锁问题（四）

一、InnoDB行锁实现方式。

     InnoDB行锁是通过给索引上的索引项来加锁实现的，如果没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁。InnoDB行锁分三种情形。

（1）Record lock ：对索引项加锁。

（2）Grap lock：对索引项之间的”间隙”、第一条记录前的“间隙”，或者最后一条记录后的“间隙”加锁。

（3）Next-key lock：前两种的组合，对记录及其前面的间隙加锁。

InnoDB这样行锁实现的特点意味着：如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果和表锁一样。

在实际的应用中，需要特别注意行锁的这一特性，否则导致大量的锁冲突，从而影响并发性能。

下面通过例子说明情况。

a、不通过索引条件查询时，Innodb会锁定表中所有记录。

如果开始tab_no_index没有索引。

    从上面表格中可以看出，session1只给一行添加排他锁，但session2在请求其他排他锁的时，却出现了锁等待！原因就是在没有锁等待的情况下，InnoDB会给所有记录添加排他锁。如果表有索引时，InnoDB就只锁定了符合条件的行，如下图所示：

创建tab_with_index表，id字段为普通的索引。

（b）、由于MySQL的行锁是争对索引添加的锁，不是争对记录添加的锁，所以虽然是访问不同的行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。设计的使用应该特别注意这一点。

（c）、当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，无论是使用主键索引，唯一索引或者普通索引，InnoDB都会使用行锁来加锁。

（d）、即使在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如一些很小的表，他就不会使用索引，这种情况InnoDB会对所有的记录添加行锁。

因此在分析锁冲突时，别忘记检查sql的执行计划，以确认是否真正使用索引。下面的例子中，检索值得数据类型和索引字段不同，虽然MySQL可以进行数据类型转换，但却不会使用索引，从而导致InnoDB给索引记录添加行锁。通过explain检查两条SQL的执行计划，可以清楚看到这一点。

栗子中，tab_with_index表的name字段有索引，但是name字段是varchar类型，如果where条件中，不是和varchar类型进行比较，则会对那么进行隐式的数据类型转换，导致索引无法使用，走了全表扫描。