一次线上 update SQL调优分享

这几周系统访问量也是居高不下,不出意外系统又出现瓶颈了,大量用户反馈判题结果响应太慢;经排查,又是关于SQL的问题

业务背景

一个类似于力扣在线做题的代码评测模块,用户提交判题任务后,后台会进行异步判题,前端会轮询判题结果,如下图

线上问题

大量的用户在前端提交后,一直都轮询不到判题结果。经代码排查,发现问题就出现在判题结果写库逻辑,耗时竟然有1s多。

而我们的判题结果写库 分为两个步骤

  1. 更新 这道题的提交数量,正确率等等
bash 复制代码
 可以简单理解为       
 update  xxxx  where  topic_id = xxx
 ​
 //topic_id是索引
  1. 将用户的判题结果写库
lua 复制代码
 逻辑较多,可以理解为多次insert,和用户维度的update.

问题分析

查看方法调用日志, 发现 第一个步骤(更新这道题的提交数,正确率)占据了80%的耗时。

当我们 update xxxx where topic_id = xxx时,MySQL会对topic_id 索引加行锁,由于第一个步骤和第二个步骤又在同一个事务。

当高并发时,用户做题是多对一的关系,大量用户可能都在写一道题,造成题目ID的行锁竞争激烈,更新题目提交数、正确率的行锁在更新玩之后不会释放;还需等待第二步,将结果写库完后(等事务执行完后)。这样行锁的无效持有时间或者叫行锁的持有粒度就增加了。

解决问题

按问题解决,直接减小行锁的粒度。

将1、2两个步骤交换下顺序。交换后逻辑变为:

  1. 将用户的判题结果写库
lua 复制代码
 逻辑较多,可以理解为多次insert,和用户维度的update.
  1. 更新 这道题的提交数量,正确率等等
bash 复制代码
 可以简单理解为       
 update  xxxx  where  topic_id = xxx
 ​
 //topic_id是索引

你可以简单的理解为 原先老逻辑是 先update,再insert。现在是先insert再update;这样行锁的持有粒度就降低了。

经此一役,判题结果写库的逻辑从原来的 400TPS直接拉高到2000多TPS!!!

总体

再总结一下,本篇通过线上判题结果的业务逻辑 分享SQL读写的调优小技巧,先insert再update,可以降低行锁的粒度,提高TPS。

相关推荐
.格子衫.2 小时前
Spring Boot 原理篇
java·spring boot·后端
安当加密2 小时前
达梦数据库TDE透明加密解决方案:构建高安全数据存储体系
网络·数据库·安全
Jabes.yang4 小时前
Java求职面试实战:从Spring Boot到微服务架构的技术探讨
java·数据库·spring boot·微服务·面试·消息队列·互联网大厂
兮动人5 小时前
Spring Bean耗时分析工具
java·后端·spring·bean耗时分析工具
华洛5 小时前
公开一个AI产品的商业逻辑与设计方案——AI带来的涂色卡自由
前端·后端·产品
追逐时光者5 小时前
C#/.NET/.NET Core技术前沿周刊 | 第 57 期(2025年10.1-10.12)
后端·.net
阿巴~阿巴~5 小时前
Redis 核心文件、命令与操作指南
数据库·redis·缓存·客户端·服务端
koping_wu5 小时前
【Redis】用Redis实现分布式锁、乐观锁
数据库·redis·分布式
abcefg_h6 小时前
关系型数据库与非关系型数据库
数据库·nosql
间彧6 小时前
Spring Bean生命周期中init-method详解与项目实战
后端