【学习笔记】MySQL死锁及热点行问题

最新推荐文章于 2024-04-25 22:58:16 发布

走了一些弯路

最新推荐文章于 2024-04-25 22:58:16 发布

阅读量276

点赞数

分类专栏： java基础文章标签： mysql 死锁热点行 MySQL优化

本文链接：https://blog.csdn.net/zhanghailang1/article/details/134285063

版权

java基础专栏收录该内容

34 篇文章 0 订阅

订阅专栏

案例

一个并发比较大的下单接口；
包括

step1 扣减商品库存
step2 生成订单数据
step3 记录操作记录

伪代码如下，底层使用的是MySQL数据库，单体服务(你问我为什么单体，案例需要啦)。

提问：暂时不考虑分布式锁、缓存、异步等使用场景，下面的代码执行步骤有没有值得优化的点？

  @Transactional(rollbackFor = Exception.class)
  public void createOrder(Entity param){
       ...校验等
      //step1 扣减商品库存
      //update products set stock = stock where sku_id = XXX
      deductStock(param);
      //step2 生成订单数据
      //insert into order XXXXXX
      createOrder(param);
      //step3 记录操作记录
      //insert into operation_records XXX
      recordOperation(param);
      ... 
  }

上述代码做了哪些事，开启了事务

更新了一个个表：库存表库存分

插入了两条数据：用户订单表，用户操作记录

对于当前的业务，上述代码的DB执行流程是没有问题的，

但是朋友，我们是要有梦想滴，CRUD BOY不是我们的终点，我们的目标是星辰大海。

来，键盘给你，优化下。

优化思路

正常业务情况下，上述代码没毛病，开启事务，库存更新语句会加上行锁，插入语句可能会加上插入意向锁等。

我们重点来关注下更新语句的行锁，并发高的情况下，同一种库存商品数据是根据sku_id来更新，存在激烈的行锁竞争抢占的问题。

来回忆一下，MySQL事务开启后，是什么时候开始给库存加行锁的？

事务开启就加行锁？错。
是在执行更新语句的时候加锁的，上述的step1。

那么解锁是什么时候呢？

当然是事务提交的时候。

那么对于案例中的语句来说，products表的sku_id = XXX这行数据的行锁，将从step1开始锁定，直到createOrder()方法执行完毕才会解锁。

对于其他的创建订单请求，热点商品，相同的sku_id，同时执行这行代码的时候，只能等待。

这样分析可以发现，持有锁的时间太长了。

没错，是时间太长了，换个场景，或许我会欣喜若狂，彷佛得到了认可，

但此时此刻，这并不是我想要的。

那么，是否可以将更新库存的语句放到最后呢，step1 变成step3，这样对一一次创建订单的请求，加锁的时长会大大减少，并发度会提升。

  @Transactional(rollbackFor = Exception.class)
  public void createOrder(Entity param){
       ...校验等
      //step1 生成订单数据
      //insert into order XXXXXX
      createOrder(param);
      //step2 记录操作记录
      //insert into operation_records XXX
      recordOperation(param);
      //step3 扣减商品库存
      //update products set stock = stock where sku_id = XXX
      deductStock(param);
      ... 
  }