在实现列表数据上移和下移功能时，遇到由于原始代码导致的排序问题，表现为index字段重复，影响功能正常运作。通过改进代码，将原本的上移和下移接口合并为一个交换接口，接收两个ID进行交换，但该方案仍存在多次数据库查询和更新。为提高效率，最终采用SQL语句直接交换两条记录的index，解决了重复index和性能问题。
背景需求：最近做列表数据上移和下移功能，数据库有个index字段用来存储当前对象的排列序号；
第一版代码是同事写的，上移和下移功能分成两个接口，上移的时候将index-1；下移的时候将index+1；
这个方式，真的是无力吐槽；
测试人员反馈的bug信息是，排序几次之后就失去了排序功能，点击上移和下移列表并没有什么变化，或者是会一下子跳几格；
好嘛，查看数据库，一堆index重复
第二版代码我将两个接口合并成了一个交换接口，实际上前端传递两个id，当前对象的id和需要交换对象的id给我就OK了，剩下的逻辑部分后端来实现；
业务层代码如下：
这段代码写好测试后就没再管，中规中矩的逻辑，但是中间查询了两次数据库更新了两次数据库，请求时间有点长，不过没有立即优化；下图是用postman测试接口时反馈的请求时间
过了几天，测试人员又提交了一次bug，说还是这个问题啊，我点击上移或者下移几次之后又出现了之前的情况啊，只不过这次出现的时候我需要很快的点击鼠标才行
没办法，再看数据库，又是一堆重复的index，我在自己电脑上吭哧吭哧打断点，就是没问题啊，然后怀疑是前端调用接口的时候重复调用，请求前端工程师加锁判断，证据呢？你怎么证明是我反复调用的问题导致的这个bug啊？无果，自己的bug自己改啊
第三版代码改为SQL语句直接交换两条记录
最低0.47元/天 解锁文章
扫一扫
1065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
