一次线上 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。

相关推荐
岫珩几秒前
Ubuntu系统关闭防火墙的正确方式
后端
power 雀儿3 分钟前
集群聊天服务器---MySQL数据库的建立
服务器·数据库·mysql
心之语歌5 分钟前
Java高效压缩技巧:ZipOutputStream详解
java·后端
不死的精灵1 小时前
【Java21】在spring boot中使用ScopedValue
java·spring boot·后端
M1A11 小时前
TCP/IP协议精解:IP协议——互联网世界的邮政编码系统
后端·网络协议·tcp/ip
逸风尊者2 小时前
开发易掌握的知识:GeoHash查找附近空闲车辆
java·后端
骑着王八撵玉兔2 小时前
【性能优化与架构调优(二)】高性能数据库设计与优化
数据库·性能优化·架构
Edingbrugh.南空2 小时前
Flink MySQL CDC 环境配置与验证
mysql·adb·flink
BD_Marathon3 小时前
Ubuntu:Mysql服务器
服务器·mysql·ubuntu
程序猿阿越3 小时前
Kafka源码(一)Controller选举与创建Topic
java·后端·源码