概述
前面两篇文章介绍了MySQL的全局锁和表级锁，今天就介绍一下MySQL的行锁。
MySQL的行锁是各个引擎内部实现的，不是所有的引擎支持行锁，例如MyISAM就不支持行锁。
不支持行锁就意味着在并发操作时，就要使用表锁，在任意时刻都只能有一个更新操作在执行，这样会影响业务的并发性。这也是为什么MyISAM会被InnoDB取代的原因之一。
行锁是锁里最小粒度的锁，InnoDB引擎里的行锁的实现算法有三种：
- Record Lock：行锁，锁住记录本身
- Gap Lock：间隙锁，锁住某个范围，但不包括记录本身
- Next-Key Lock：Record Lock + Gap Lock，既锁范围，又锁记录
InnoDB是使用Next-Key Lock来解决幻读问题的。
什么是幻读？
我们看一下这个例子，有一个表 t，插入部分数据。
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `c` (`c`)
) ENGINE=InnoDB;
insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);
图1 假设只在id=5这一行加行锁
有三个会话并发执行，Session A在T1，T3，T5时刻分别查询同一个语句，出现不同的结果。其中Q3读到的id=1这一行的现象，被称为幻读。
幻读，指同一个事务中，两次相同的查询操作，得到的结果行数不一样。
这里要对“幻读”做两点说明：
- 在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。因此幻读在“当前读”下才会出现。
- 上面的Session B的修改结果，被Session A之后的select语句用“当前读”看到了，不能称为幻读。幻读仅专指“新插入的行”。
根据数据可见性规则分析，这三个查询都加了for update，都是“当前读”，符合数据可见性规则。
这么看来，好像没什么问题，是不是真的没有问题呢？
不，这里还真就有问题。
幻读有什么问题？
语义上不一致
Session A在T1时刻就声明了，“我要把所有d=5的行锁住，不准别的事务进行读写操作”。而实际上，这个语义被破坏了。
上面的例子可能还看不太出来，我们给Session B和Session C分别加两个语句，再看看会出现什么现象。
图2 假设只在id=5这一行加行锁--语义被破坏
Session B的第二条语句update t set c = 5 where id=0，语义是“我要把id=0、d=5的这一行的c的值改成了5”。
由于在T1时刻，Session A还只是给t=5这一行加了行锁，并没有给id=0这一行加锁。因此Session B在T2时刻，是可以执行这条语句的。
同理，Session C对id=1这行的修改，一样是破坏了Q1的加锁声明。
数据上不一致
其次是造成数据上不一致。锁的设计就是为了保证数据一致性的，这里的一致性除了内部数据在此刻的一致性外，还包含数据和日志在逻辑上的一致性。
图 3 假设只在id=5这一行加行锁--数据一致性问题
我们来分析一下图3执行完成后，数据库的数据是什么：
- 经过T1时刻，id=5这一行变成 (5,5,100)，当然这个结果最终是在T6时刻正式提交的
- 经过T2时刻，id=0这一行变成(0,5,5);
- 经过T4时刻，表里面多了一行(1,5,5);
我们再来看看binlog的内容：
// session B
update t set d=5 where id=0;
update t set c=5 where id=0;
// session C
insert into t values(1,1,5);
update t set c=5 where id=1;
update t set d=100 where d=5;
按照这个语句序列，这三行的结果变成：(0,5,100),(1,5,100),(5,5,100)。
也就是说id=0和id=1这两行，发生了数据不一致。这个问题很严重，是不行的。
那究竟这个数据不一致是怎样引入的呢？
图 4 假设扫描到的行都被加上了行锁
假设我们对扫描到的行都加上行锁，来看看图4执行后会出现什么现象。
- 经过T1时刻，id=5这一行变成 (5,5,100)，当然这个结果最终是在T6时刻正式提交的
- 经过T2时刻，Session B被阻塞，等到T6时刻Session A释放锁才能执行;
- 经过T4时刻，表里面多了一行(1,5,5);
- 经过T6时刻，id=1这一行变成(1,5,100)；
id=1这一行还是出现数据不一致的问题。即使把所有的记录都加上锁，还是阻止不了新插入的记录。
如何解决幻读？
我们现在知道产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB引入了间隙锁（Gap Lock）。
前面介绍过，间隙锁，锁住某个范围，但不包括记录本身。比如前面说到的表t，初始化有6条记录，这就产生了7个间隙。
图 5 表t主键索引上的行锁和间隙锁
当你执行select * from t where d=5 for update的时候，就不止是给数据库中6个记录加了行锁，还同时加了7个间隙锁。这样就确保了无法再插入新的记录。
也就是说这时候，在一行行扫描的过程中，不仅给行加上行锁，还给行两边的空隙也加上间隙锁。
我们回到上面的图4，再来看看加上间隙锁后，执行的效果如何。
- 经过T1时刻，id=5这一行变成 (5,5,100)，当然这个结果最终是在T6时刻正式提交的。因为select * from t where d=6 for update，对6个记录加了行锁，同时加了7个间隙锁。
- 经过T2时刻，Session B被阻塞，因为id=0这一行被锁;
- 经过T4时刻，Session C被阻塞，因为主键索引上加了间隙锁(0,5)，所以id=1这个值无法被插入;
Session B和Session C都要等待Session A释放锁后才能继续执行，这样就解决了幻读的问题。
行锁保证更新行，间隙锁保证插入行，而行锁+间隙锁=Next-Key Lock，也就是本文开头说到的，InnoDB是通过Next-Key Lock来解决幻读问题的。
但是间隙锁的引入，可能会导致同样的语句锁住更大的范围，这会影响并发度的。比如上面的select * from t where d=5 for update，相当于加了表锁。