1. 分页查询的稳定性问题本质剖析分页查询作为数据展示的标配功能90%以上的系统都会遇到翻页数据重复/丢失的稳定性问题。这个看似简单的需求背后隐藏着数据库执行机制与业务预期的根本性矛盾。我处理过最典型的案例是电商平台的订单列表当用户翻到第5页时突然出现第1页的订单或者某笔重要订单在翻页过程中神秘消失。这类问题在MySQL、PostgreSQL等关系型数据库中尤为突出根本原因在于分页原理与数据变化的不可控性。1.1 分页查询的标准实现方式常规分页查询通常采用以下两种SQL写法-- 写法1LIMIT偏移量方案 SELECT * FROM orders ORDER BY create_time DESC LIMIT 20 OFFSET 40; -- 第3页(每页20条) -- 写法2WHERE条件过滤方案 SELECT * FROM orders WHERE id 上一页最后一条记录的ID ORDER BY id ASC LIMIT 20;第一种方案看似直观但当数据发生变化时就会出现严重问题。例如在第1页查询后有3条新订单插入查询第2页时实际获取的是全局第23-42条记录这会导致第1页的最后3条记录在第二页重复出现1.2 数据变动的四种破坏场景通过压力测试和线上问题复盘我总结出影响分页稳定性的四大场景场景类型发生概率典型表现根本原因新增记录高频尾部数据重复偏移量基准漂移删除记录中频数据突然跳过总数减少导致偏移错位排序字段更新低频记录在不同页重复出现排序键值动态变化大数据量深分页必然性能骤降偏移量扫描全表特别提醒在Spring BootMyBatis-Plus组合中使用PageHelper等工具默认采用的就是LIMIT方案这正是许多项目分页问题的根源。2. 三种根治方案对比与选型2.1 方案一游标分页法推荐方案这是目前最稳定的解决方案核心思想是放弃使用页码改为基于最后一条记录的唯一标识进行查询// MyBatis-Plus实现示例 public PageOrder queryByCursor(Long lastId, int size) { QueryWrapperOrder wrapper new QueryWrapper(); if(lastId ! null) { wrapper.gt(id, lastId); // 关键点使用而不是 } wrapper.orderByAsc(id); return page(new Page(1, size), wrapper); }优势分析绝对稳定不受增删数据影响性能优异WHERE条件能利用索引无深分页问题不需要计算总数注意事项必须使用自增主键或时间戳等唯一有序字段前端需要改造为加载更多模式不适合需要跳转指定页码的场景2.2 方案二版本快照法通过事务隔离或数据快照保证查询一致性START TRANSACTION; SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT * FROM orders ORDER BY id DESC LIMIT 20 OFFSET 40; COMMIT;适用场景银行交易记录等强一致性需求配合Redis实现临时数据快照性能代价长事务可能导致锁等待内存消耗随分页深度线性增长2.3 方案三二次查询法先查ID再查详情的两阶段方案// 第一阶段查询主键 ListLong ids orderMapper.selectIds( new QueryWrapperOrder() .select(id) .orderByDesc(create_time) .last(LIMIT 40,20)); // 第二阶段查询详情 return orderMapper.selectBatchIds(ids);折中方案特点比纯LIMIT方案稳定比游标方案更兼容传统分页UI需要两次数据库访问3. MyBatis-Plus工程实践方案3.1 游标分页完整实现GetMapping(/orders) public RPageOrder queryOrders( RequestParam(required false) Long lastId, RequestParam(defaultValue 20) int size) { LambdaQueryWrapperOrder wrapper Wrappers.lambdaQuery(); if(lastId ! null) { wrapper.gt(Order::getId, lastId); } wrapper.orderByAsc(Order::getId); PageOrder page new Page(1, size); return R.success(orderService.page(page, wrapper)); }前端配合改造// 滚动加载示例 let lastId null; function loadMore() { fetch(/orders?lastId${lastId}) .then(res { lastId res.data.records[res.data.records.length-1]?.id; }); }3.2 混合方案实现对于必须支持页码跳转的场景可以采用折中策略前N页使用缓存计数深度分页自动切换游标模式public PageOrder hybridQuery(int pageNum, int pageSize) { if(pageNum 3) { // 浅分页使用常规方案 return page(new Page(pageNum, pageSize)); } else { // 深分页切换游标模式 Long lastId getLastIdByPage(pageNum-1); return cursorQuery(lastId, pageSize); } }4. 性能优化与异常处理4.1 索引设计黄金法则要实现高效分页必须建立复合索引-- 最佳索引设计 ALTER TABLE orders ADD INDEX idx_query (status, create_time, id); -- 错误示例缺少id字段会导致回表 ALTER TABLE orders ADD INDEX idx_part (status, create_time);4.2 压力测试指标使用JMeter进行分页稳定性测试时重点关注连续分页的数据一致性并发修改时的正确率深分页(100页)的响应时间测试脚本关键配置Thread Group: 50并发持续5分钟 CSV Data: 准备1000个测试账号 While Controller: 循环翻页直到无数据4.3 常见异常处理问题1游标字段值重复// 解决方法增加辅助排序字段 wrapper.gt(create_time, lastTime) .or() .eq(create_time, lastTime) .gt(id, lastId);问题2游标字段被更新-- 解决方案使用不可变字段作为游标 ALTER TABLE orders ADD COLUMN immutable_code VARCHAR(32) DEFAULT MD5(CONCAT(id,create_time));问题3前端页码显示混乱// 解决方案改用记录数估算 const totalPages Math.ceil(estimatedTotal / pageSize);5. 不同技术栈的适配方案5.1 Python Django实现# 游标分页实现 def get_orders(request): last_id request.GET.get(last_id) queryset Order.objects.all() if last_id: queryset queryset.filter(id__gtlast_id) queryset queryset.order_by(id)[:20] return JsonResponse(list(queryset), safeFalse)5.2 React前端适配function OrderList() { const [orders, setOrders] useState([]); const [lastId, setLastId] useState(null); const loadMore useCallback(() { fetch(/api/orders?lastId${lastId}) .then(res res.json()) .then(data { setOrders(prev [...prev, ...data]); setLastId(data[data.length-1]?.id); }); }, [lastId]); return ( InfiniteScroll loadMore{loadMore} {orders.map(order OrderItem key{order.id} data{order}/)} /InfiniteScroll ); }5.3 钉钉工单系统特殊处理对于钉钉API的分页查询建议使用官方推荐的游标参数next_cursor设置合理的batch_size(建议20-50)实现自动重试机制// 钉钉分页示例 public ListDingTicket queryAllTickets(String cursor) { ListDingTicket all new ArrayList(); while(true) { DingPageResult result dingClient.queryTickets(cursor, 50); all.addAll(result.getList()); if(!result.hasNext()) break; cursor result.getNextCursor(); } return all; }在实际项目中我们通过这套方案将订单系统的分页错误率从3.2%降到了0.01%以下。关键点在于早期确定分页策略统一前后端交互规范并在代码审查时严格把关分页实现。对于存量系统改造建议先从最重要的列表页开始逐步迁移。