对于刚学的同学和像我一样已经有几年开发经验的朋友，一提到 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默认的事务等级下的锁机制决定了其是行锁。
