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

业务背景

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

线上问题

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

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

1. 更新 这道题的提交数量，正确率等等

 可以简单理解为       
 update  xxxx  where  topic_id = xxx
 ​
 //topic_id是索引

1. 将用户的判题结果写库

 逻辑较多，可以理解为多次insert，和用户维度的update.

问题分析

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

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

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

解决问题

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

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

1. 将用户的判题结果写库

 逻辑较多，可以理解为多次insert，和用户维度的update.

1. 更新 这道题的提交数量，正确率等等

 可以简单理解为       
 update  xxxx  where  topic_id = xxx
 ​
 //topic_id是索引

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

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

总体

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