For|For update 真的是行锁吗()

对于刚学的同学和像我一样已经有几年开发经验的朋友,一提到 For update ,不就是为了更新而存在的查询语句嘛,在查询后,这条记录会被一直锁定无法被其他事务修改,直到本次事务提交。
网上也是铺天盖地的都是这类说法。
For|For update 真的是行锁吗()
文章图片
这类说法对,也不全对。
因为今天的一次线上错误,让我又重新认识了一下 For update 这位熟悉又陌生的朋友。
(本文均以 Mysql举例)
具体理论知识参考:数据库的事务等级(事务的隔离级别)
我们知道根据事务的基本要素和会产生的并发问题,引出 MYSQL 的事务隔离级别:
For|For update 真的是行锁吗()
文章图片


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


【For|For update 真的是行锁吗()】我们先看下这段代码


For|For update 真的是行锁吗()
文章图片


这个是我从 git 的提交历史中截的图,大家可以看下第二行和第三行的区别。
没错,第二行是显式的支出本次事务的传播范围是新创建事务这个类型(Spring
事务传播类型)。
这就为程序的错误埋下了伏笔。按照网上和以往的认知 For update 语句是行锁,并且可以保证可重复读这一并发问题。那它和 Mysql 目前的默认事务隔离级别一样,为什么还需要锁这一概念呢?


错误又是如何发生的呢?


问题重现:


一个简单的发布任务逻辑,任务发布的同时会去创建任务和订单,然后针对任务进行支付,这里存在一个事务的嵌套逻辑。即发布任务和创建订单是一名同学开发的,而支付部分是专门的一名同学开发的,支付的同学给发布任务的同学提供接口调用,这两块都存在事务,本身按照
Spring 的默认事务传播级别是 REQUIRED 类型(即如果有事务就加入该事物,如果没有就新增事务)但开发任务的同事将支付的这一接口的事务传播等级改为了 REQUIRED_NEW(当前的方法必须启动新事物,如果有原事务就将其挂起),在调用支付前该同学进行了一次ID
生成规则的执行(For update 语句),在支付时就报错了,因为支付的时候由于资金明细也需要生成一次
ID 规则这个时候原来被进行 For update 的那条语句所在的事务并未提交而是被挂起了就导致事务更新超时,然后就抛出「Lock wait timeout exceeded; try restarting transaction」。


For|For update 真的是行锁吗()
文章图片
对于我这种灵性的感觉看到这个问题就断定没这么简单。
因为对于我的认知而言 For update 是行锁,ID 生成表里任务 ID 和资金明细 ID 的生成规则是两条记录,为什么会出现影响呢?难道 For update 进行了锁表?


然后我就对 SELECT 语句进行了 EXPLAIN ,证明了我的想法。
For|For update 真的是行锁吗()
文章图片
它为什么会扫描 7行呢?一个表也就 7 条记录呀。通过 ID 进行的查询为什么不会走索引呢?
Wish today!
For|For update 真的是行锁吗()
文章图片
Id 竟然不是主键!那当然不会走索引了!那肯定是扫描全表!


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


由于
1.ID 生成表没有主键,导致 「SELECT* FROM table where id = *For update」未能走索引,扫描了全表。
2. 事务的传播机制导致原事务挂起未能提交,导致For update 的锁无法被释放,新的事务无法提交导致事务超时。
3. 对于 For update 是行锁这一理解是不准确的,是否是行锁还是表锁是根据索引而言,是否有索引在不同的事务等级下行锁和表锁也是不同的,需要具体问题具体分析,但可以这样说,如果是走索引的话,是行锁是没问题的,毕竟Mysql默认的事务等级下的锁机制决定了其是行锁。

    推荐阅读