分页查询在某些场景下引发的数据漏处理问题

简介: 分页查询在某些场景下引发的数据漏处理问题

背景

问题描述

假设有一个表字段statues,我们分页获取数据。status初始状态为1,我们分批获取数据,每一批获取1000,对数据进行处理,如果处理成功就更新status为2,否则不更新。

注意事项:

分页循环查询满足条件的数据然后进行处理,通过PageHelper或者直接使用“limit statIndex,pageSize”来分页查看数据,如果查询条件(如根据status来过滤数据)在每一次获取之后会更改,这里的更改可能指的是在每次循环查询内部更改满足查询条件的数据,如status=1的条件,在查询完之后更改为status=2,注意这里的更改还有可能出现在另外的逻辑链条中。

又或者将status=1的记录删除,或者再增加新的status=1的记录,这些都是类似问题,都会导致分页的数量

原有代码

List<User> userList;
int startPage = NumberUtils.INTEGER_ONE;
int bachSize = 10;
do {
    PageHelper.startPage(startPage, bachSize);
    // 查询用户列表
    userList = userMapper.listNeedApproveUser(xxx);
    if (CollectionUtils.isNotEmpty(userList)) {
        for (User user : userList) {
            // 处理用户审核状态
            int updNum = userMapper.updateApproveStatus(yyy);
        }
    }
    startPage++;
} while (userList.size() == bachSize);

分页查询后的变更过程如下

我们看到,原本在第二页的数据跑到第一页去了,而我们找第二页数据时,6、7两条数据就被丢弃了。相信看图大家都应该看懂了,道理也很简单,但在做得时候却忽略了。

更新之后的代码

针对上面所说的分页查询方式,我们需要做一些调整,调整办法如下:

  • 第一步:当查询出当页的数据之后,记录下本次拉取的最后一条数据的排序字段值;当发起下一页数据查询的时候,带上这个参数,服务端通过这个参数做过滤条件
  • 第二步:排序字段值不能出现重复
List<User> userList;
int bachSize = 10;
Long idGreater = NumberUtils.LONG_ZERO;
do {
// 查询用户列表select * from user where approve_status = #{approveStatus} and id > ${idGreater} order by id asc limit ${pageSize}
userList = userMapper.listNeedApproveUser(xxx, idGreater, bachSize);
if (CollectionUtils.isEmpty(userList)) {
break;
}
// 将本次循环查询到的最大id作为下次执行的startIndex,id > #{startIndex}
idGreater = userList.get(userList.size() - 1).getId();
for (User user : userList) {
// 处理用户审核状态
int updNum = userMapper.updateApproveStatus(yyy);
}
} while (transferImeiDetailList.size() == MAX_BATCH_SIZE);

相关文章

https://zhuanlan.zhihu.com/p/617014259

本篇文章如有帮助到您,请给「翎野君」点个赞,感谢您的支持。


目录
相关文章
|
负载均衡 网络协议 安全
slb选择监听协议和端口
阿里云SLB中,监听协议(TCP、HTTP、HTTPS)与端口(80、443等)决定客户端请求的处理方式。TCP适用于纯TCP或自处理HTTP的场景,HTTP用于智能调度Web服务,HTTPS提供安全的HTTP传输。监听端口通常匹配应用标准,如80 for HTTP,443 for HTTPS。配置时,可考虑HTTPS重定向和传递`X-Forwarded-Proto`头以识别请求来源。选择应基于业务需求和安全考虑。
908 3
|
消息中间件 SQL Java
Flink自定义Connector
Flink自定义Connector
1050 0
|
15天前
|
Ubuntu API 数据安全/隐私保护
OpenClaw“小龙虾”进阶保姆级图文教程!阿里云/本地部署+多Agent选型+百炼Coding Plan配置及避坑指南
2026年,OpenClaw的用户讨论焦点已从“如何安装”转向“如何用好”,其中多Agent玩法成为核心热点。但多数用户容易陷入“为了复杂而复杂”的误区——还未找到稳定使用场景,就盲目搭建十几个Agent,最终因维护成本过高而放弃。
829 1
|
5天前
|
人工智能 数据挖掘 Linux
OpenClaw多智能体完整配置:4开并行、路由隔离、Agent通信与阿里云端/本地部署图文教程
在AI智能体深度落地的2026年,单Agent通用助手已经无法满足专业化、并行化、隔离化的业务需求,单一上下文无法同时承载代码开发、内容创作、数据分析、财务统计等多领域记忆与规则。OpenClaw提供的多Agent架构可以在**一台服务器上同时运行多个完全独立的AI员工**,每个Agent拥有专属工作区、独立记忆、独立人设、独立模型配置、独立消息通道,互不干扰且可互相协同,真正实现“一人一机一公司”的轻量化团队架构。本文基于真实生产环境实战,完整讲解OpenClaw多Agent创建、工作区隔离、通道绑定、路由规则、Agent间通信、权限配置的全流程,同时提供2026年阿里云服务器部署、MacO
724 8
|
12月前
|
缓存 NoSQL Java
G1原理—9.如何优化G1中的MGC
本文主要探讨了因大对象导致频繁Mixed GC的问题及其优化方案。通过一个电商平台缓存更新的案例,分析了商品信息大量写入缓存时引发的GC问题,包括Redis锁等待、大对象分配及RegionSize调整不当等原因。文章详细介绍了Mixed GC的优化策略,分为避免策略(如调整RegionSize和新生代大小)与提速策略(如提升分配与回收速度),并深入解析了相关参数(如InitiatingHeapOccupancyPercent、G1ReservePercent等)的作用与调优方法,为解决类似性能问题提供了全面指导。
371 15
G1原理—9.如何优化G1中的MGC
|
编译器
stm32使用CubeMx配置蜂鸣器
stm32使用CubeMx配置蜂鸣器
3422 0
|
消息中间件 网络协议 Linux
|
存储 机器学习/深度学习 人工智能
基于Megatron-Core的稀疏大模型训练工具:阿里云MoE大模型最佳实践
随着大模型技术的不断发展,模型结构和参数量级快速演化。大模型技术的应用层出不穷。大模型展现惊人效果,但训练和推理成本高,一直是巨大挑战。模型稀疏化能降低计算和存储消耗。近期以Mixtral为代表的MoE(多专家混合)大模型证明了稀疏MoE技术能大幅降低计算量、提升推理速度,模型效果甚至超过同规模稠密模型。阿里云PAI和NVIDIA团队深入合作,基于Megatron-Core MoE框架,解决了MoE大模型训练落地时会遇到的可拓展性、易用性、功能性以及收敛精度等核心问题,在下游任务上取得了很好的模型效果。
|
SQL Java 数据库连接
SpringBoot中事务执行原理分析(六)
SpringBoot中事务执行原理分析(六)
823 0
|
运维 负载均衡 Java
nacos常见问题之Feign无法互相如何解决
Nacos是阿里云开源的服务发现和配置管理平台,用于构建动态微服务应用架构;本汇总针对Nacos在实际应用中用户常遇到的问题进行了归纳和解答,旨在帮助开发者和运维人员高效解决使用Nacos时的各类疑难杂症。

热门文章

最新文章