1. 问题现象与初步排查
最近在开发后台管理系统时，遇到了一个诡异的问题：分页查询时明明数据库里有数据，但接口返回的结果集却显示为空。这个问题在测试环境偶发出现，到了生产环境频率明显升高。作为一名有五年经验的Java后端开发者，我决定彻底排查这个"幽灵数据"问题。
首先通过Postman复现问题场景：当pageSize=10，pageNum=3时返回空数组，但用Navicat执行COUNT查询发现符合条件的记录有35条。这种不一致性说明问题出在数据查询环节而非数据存储层。以下是初步排查时记录的典型现象特征：
- 仅出现在特定分页（通常是非第一页）
- 数据总量越大出现概率越高
- 排序字段使用create_time时更易触发
- 生产环境出现频率是测试环境的5倍以上
2. 核心原因深度分析
2.1 分页原理与潜在陷阱
以MySQL为例，常规分页查询语句形如：
SELECT * FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 10 OFFSET 20这里隐藏着三个关键风险点：
- 非稳定排序：当create_time相同时，数据库实际返回顺序可能不一致
- 数据变动干扰：查询过程中如有新数据插入，可能导致分页漂移
- OFFSET性能陷阱：大数据量下OFFSET会扫描跳过所有前置记录
2.2 并发场景下的数据可见性
通过分析生产环境日志，发现一个关键现象：问题集中出现在促销活动期间。这指向了MVCC（多版本并发控制）机制的影响：
- 事务隔离级别为REPEATABLE-READ时
- 分页查询事务开始时，会建立一致性视图
- 其他事务新增的数据对该查询不可见
- 导致后续分页出现"数据消失"假象
3. 解决方案与实施细节
3.1 基于游标的稳定分页
采用last_id分页模式替代传统OFFSET：
public PageInfo<User> listUsers(Long lastId, int pageSize) { // 使用索引列作为游标 List<User> users = userMapper.selectAfterId( lastId, pageSize, SortField.CREATE_TIME ); // 构建下一页的游标 Long nextLastId = users.isEmpty() ? null : users.get(users.size()-1).getId(); return new PageInfo(users, nextLastId); }优势分析：
- 避免OFFSET全表扫描
- 不受新增数据影响
- 排序稳定性由主键保证
3.2 事务隔离优化方案
对于必须使用OFFSET的场景，调整事务策略：
# Spring配置 spring: datasource: hikari: isolation-level: READ-COMMITTED配套代码改造：
@Transactional(isolation = Isolation.READ_COMMITTED) public PageData getPagedOrders(int pageNum) { // 分页查询逻辑 }4. 生产环境验证与性能对比
在订单服务实施改造后，通过JMeter压测对比：
| 方案类型 | QPS | 平均耗时 | 错误率 |
|---|---|---|---|
| 传统OFFSET | 128 | 450ms | 12% |
| 游标分页 | 210 | 210ms | 0% |
| READ-COMMITTED | 185 | 280ms | 1.5% |
关键发现：
- 游标分页性能提升64%
- 数据不一致问题完全解决
- 内存消耗降低约30%
5. 特殊场景处理方案
5.1 多字段排序场景
当需要按非唯一字段排序时（如按价格分页），采用组合游标：
SELECT * FROM products WHERE (price, id) > (lastPrice, lastId) ORDER BY price, id LIMIT 105.2 前端适配改造
前端需要调整分页组件逻辑：
async function loadPage(lastId) { const res = await api.get('/list', { params: { last_id: lastId, size: 10 } }); // 更新下一页游标 store.setLastId(res.data[res.data.length-1]?.id); }6. 经验总结与避坑指南
索引设计黄金法则：
- 分页查询字段必须建立联合索引
- 例如
(status, create_time, id)三字段索引 - 索引顺序与ORDER BY顺序严格一致
JPA/Hibernate特殊配置：
@Query(nativeQuery = true, value = "SELECT * FROM items WHERE id > ?1 ORDER BY id LIMIT ?2") List<Item> findAfterId(Long lastId, int limit);MyBatis分页插件陷阱：
- PageHelper的
startPage()必须紧跟查询语句 - 中间不能有其他查询操作
- 建议使用
PageMethod的lambda形式
- PageHelper的
ES分页的特殊处理：
SearchAfterBuilder builder = new SearchAfterBuilder(); builder.setSortValues(lastSortValues); searchSourceBuilder.searchAfter(builder);这个问题的排查过程让我深刻认识到：看似简单的分页查询，在并发场景下会变成分布式系统的一致性问题。建议所有后端开发者在设计分页接口时，都应该默认采用游标分页模式，这不仅能解决"幽灵数据"问题，还能显著提升系统性能。
