For update 真的是行锁吗？

对于刚学的同学和像我一样已经有几年开发经验的朋友，一提到 For update ，不就是为了更新而存在的查询语句嘛，在查询后，这条记录会被一直锁定无法被其他事务修改，直到本次事务提交。

网上也是铺天盖地的都是这类说法。

这类说法对，也不全对。

因为今天的一次线上错误，让我又重新认识了一下 For update 这位熟悉又陌生的朋友。

（本文均以 Mysql举例）

具体理论知识参考：数据库的事务等级（事务的隔离级别）

我们知道根据事务的基本要素和会产生的并发问题，引出 MYSQL 的事务隔离级别：

为什么会扯上这个呢？因为这个问题的起因是这个导致。

我们先看下这段代码

这个是我从 git 的提交历史中截的图，大家可以看下第二行和第三行的区别。

没错，第二行是显式的支出本次事务的传播范围是新创建事务这个类型（Spring

事务传播类型）。

这就为程序的错误埋下了伏笔。按照网上和以往的认知 For update 语句是行锁，并且可以保证可重复读这一并发问题。那它和 Mysql 目前的默认事务隔离级别一样，为什么还需要锁这一概念呢？

错误又是如何发生的呢？

问题重现：

一个简单的发布任务逻辑，任务发布的同时会去创建任务和订单，然后针对任务进行支付，这里存在一个事务的嵌套逻辑。即发布任务和创建订单是一名同学开发的，而支付部分是专门的一名同学开发的，支付的同学给发布任务的同学提供接口调用，这两块都存在事务，本身按照

Spring 的默认事务传播级别是 REQUIRED 类型（即如果有事务就加入该事物，如果没有就新增事务）但开发任务的同事将支付的这一接口的事务传播等级改为了 REQUIRED_NEW（当前的方法必须启动新事物，如果有原事务就将其挂起），在调用支付前该同学进行了一次ID

生成规则的执行（For update 语句），在支付时就报错了，因为支付的时候由于资金明细也需要生成一次

ID 规则这个时候原来被进行 For update 的那条语句所在的事务并未提交而是被挂起了就导致事务更新超时，然后就抛出「Lock wait timeout exceeded; try restarting transaction」。

对于我这种灵性的感觉看到这个问题就断定没这么简单。

因为对于我的认知而言 For update 是行锁，ID 生成表里任务 ID 和资金明细 ID 的生成规则是两条记录，为什么会出现影响呢？难道 For update 进行了锁表？

然后我就对 SELECT 语句进行了 EXPLAIN ，证明了我的想法。

它为什么会扫描 7行呢？一个表也就 7 条记录呀。通过 ID 进行的查询为什么不会走索引呢？

Wish today！

Id 竟然不是主键！那当然不会走索引了！那肯定是扫描全表！

问题到这，根源已经找到了。

由于

   1.  ID 生成表没有主键，导致 「SELECT* FROM table where id = *  For update」未能走索引，扫描了全表。

   2. 事务的传播机制导致原事务挂起未能提交，导致For update 的锁无法被释放，新的事务无法提交导致事务超时。

   3. 对于 For update 是行锁这一理解是不准确的，是否是行锁还是表锁是根据索引而言，是否有索引在不同的事务等级下行锁和表锁也是不同的，需要具体问题具体分析，但可以这样说，如果是走索引的话，是行锁是没问题的，毕竟Mysql默认的事务等级下的锁机制决定了其是行锁。