分页查询稳定性问题与游标分页解决方案

1. 分页查询的稳定性陷阱：为什么你的列表数据总在"跳舞"？

后端开发中最令人头疼的问题之一，莫过于用户反馈"为什么我翻页时总看到重复的数据？"或者"为什么有些数据莫名其妙消失了？"。这种看似诡异的现象，根源在于传统分页查询的"锚点不稳定"特性。

想象一下图书馆的书架管理：如果管理员按照"最近上架时间"排序书籍，而你正在浏览第2页的书目时，突然有10本新书上架。此时整个书架序列会整体后移，导致你接下来看到的第2页内容实际上是原先第1页后半部分和第2页前半部分的混合体——这就是分页偏移量（offset）机制的天生缺陷。

1.1 问题复现：三个典型业务场景

场景一：社交动态流污染
当用户浏览朋友圈第2页时，如果有新动态发布，传统LIMIT 10,10查询会因为结果集偏移而重复显示第1页末尾的内容。实测数据显示，在日活百万的APP中，这种重复展示会导致约7%的用户投诉。

场景二：电商促销资损事件
某大促期间，运营后台使用常规分页发放优惠券。当新增券码时，部分用户因分页偏移获得了重复优惠券，最终造成120万元的实际损失。事后分析发现，偏移量分页在数据变化时的不可预测性是主因。

场景三：金融流水错乱
银行交易流水查询界面使用transaction_time单字段排序，由于同一秒可能存在多笔交易，导致分页时出现交易记录"跳动"。某客户因此误认为资金异常，引发投诉升级。

1.2 技术解剖：偏移量分页的致命伤

传统分页的SQL模式LIMIT offset, size存在两个结构性缺陷：

1. 动态数据集问题：offset基于行位置而非数据特征，任何数据增删都会改变后续页的内容
2. 非唯一排序问题：单字段排序（如create_time）可能导致边界值不确定

通过以下实验可以清晰看到问题本质：

sql复制-- 实验表结构
CREATE TABLE items (
  id INT AUTO_INCREMENT,
  name VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id)
);

-- 第一页查询
SELECT * FROM items ORDER BY created_at DESC LIMIT 0, 5;
-- 返回ID为 15,14,13,12,11

-- 此时插入3条新记录
INSERT INTO items (name) VALUES ('new1'),('new2'),('new3');

-- 相同条件的第二页查询
SELECT * FROM items ORDER BY created_at DESC LIMIT 5, 5;
-- 实际返回ID为 12,11,10,9,8 而非预期的10,9,8,7,6

2. 根治方案：游标分页的工程实现

2.1 方案选型矩阵

根据业务特征选择分页方案时，建议参考以下决策树：

2.2 游标分页深度实现

核心原理：用上一页最后一条记录的排序字段值作为锚点，而非行偏移量。这类似于书签——无论书架如何变化，总能准确找到上次阅读的位置。

MySQL实现要点：

1. 必须建立(created_at,id)的联合索引
2. 前端需要缓存last_cursor值
3. 边界条件处理要严谨

完整示例代码：

java复制public PageResult<List<Item>> queryByCursor(Long lastCursor, int pageSize) {
    // 首次查询
    if (lastCursor == null) {
        return itemMapper.selectFirstPage(pageSize);
    }
    
    // 后续分页
    Cursor cursor = decodeCursor(lastCursor);
    return itemMapper.selectNextPage(
        cursor.getCreatedAt(), 
        cursor.getId(), 
        pageSize);
}

// MyBatis映射
@Select("SELECT * FROM items " +
        "WHERE (created_at < #{createdAt} OR " +
        "(created_at = #{createdAt} AND id < #{id})) " +
        "ORDER BY created_at DESC, id DESC LIMIT #{size}")
List<Item> selectNextPage(
    @Param("createdAt") Date createdAt,
    @Param("id") Long id,
    @Param("size") int size);

性能对比测试：
在100万数据量的items表上，不同方案的查询耗时：

2.3 时间戳过滤方案的陷阱与突破

虽然时间戳方案实现简单，但存在三个致命陷阱：

1. 删除导致的数据空洞：当时间窗口内的数据被删除时，后续分页会出现数据丢失
2. 实时性牺牲：用户无法在分页过程中看到新数据
3. 深分页性能：LIMIT 100000,10仍然需要扫描前100010行

优化方案：动态时间窗口+ID去重

sql复制-- 改进版查询
SELECT * FROM (
  SELECT DISTINCT id FROM items
  WHERE created_at <= '2024-05-20 15:00:00'
  ORDER BY created_at DESC, id DESC
  LIMIT 100010, 10
) AS t1 JOIN items AS t2 ON t1.id = t2.id;

3. Elasticsearch场景的特别处理

3.1 search_after实战技巧

ES的search_after需要特别注意：

1. 排序字段必须包含_doc字段确保唯一性
2. 需要处理NaN和null值
3. 建议设置track_total_hits=false提升性能

高级实现示例：

java复制SearchSourceBuilder builder = new SearchSourceBuilder()
    .size(100)
    .sort("price", SortOrder.ASC)
    .sort("_doc", SortOrder.DESC); // 确保唯一性

if (lastSortValues != null) {
    builder.searchAfter(lastSortValues);
}

// 防止内存溢出
builder.trackTotalHits(false);
builder.timeout(TimeValue.timeValueSeconds(30));

3.2 性能调优参数

4. 工程规范与监控体系

4.1 代码审查清单

在CR分页查询代码时，必须检查：

1. [ ] 排序字段是否保证唯一性（必须包含ID或唯一字段）
2. [ ] 是否使用游标或时间戳替代纯offset
3. [ ] 分页参数是否有合法校验（如pageSize≤100）
4. [ ] 是否添加了防重复查询的缓存机制
5. [ ] 错误日志是否包含完整分页上下文

4.2 监控指标设计

建议在APM系统中配置以下监控：

yaml复制metrics:
  pagination:
    duplicate_rate: 
      query: "count(duplicate_items)/count(returned_items)"
      threshold: "<0.01"
    response_time:
      query: "histogram(response_time_ms)"
      buckets: [50,100,300,1000]
    missing_data:
      query: "count(expected_items - returned_items)"
      threshold: "==0"

4.3 压力测试方案

使用JMeter模拟以下场景：

1. 持续写入时的分页稳定性
2. 100并发用户的随机翻页
3. 极端情况下的深分页（如第9999页）
4. 长时间运行的游标会话保持

测试数据建议：

• 基础数据量：实际数据量的1.5倍
• 写入QPS：平日峰值的2倍
• 网络延迟：模拟4G环境（100ms±50）

5. 特殊场景解决方案

5.1 商品排序分页的二次排序

对于需要后台设置排序权的商品列表，推荐方案：

1. 基础排序字段：display_order ASC（后台配置的排序值）
2. 次要排序字段：id DESC（确保唯一性）
3. 使用游标分页传递last_display_order和last_id

sql复制SELECT * FROM products
WHERE (display_order > #{lastOrder} OR 
      (display_order = #{lastOrder} AND id < #{lastId}))
ORDER BY display_order ASC, id DESC
LIMIT 10;

5.2 分布式环境下的分页一致性

在分库分表场景中，需要额外处理：

1. 使用全局排序键（如Snowflake ID）
2. 采用中间件聚合（如ShardingSphere的归并引擎）
3. 考虑最终一致性时的分页补偿机制

java复制// 分片查询示例
List<Product> mergeResults = shardingJdbcTemplate.executeQuery(
    "SELECT * FROM products_${0..15}",
    queryParams,
    (resultSet) -> {
        // 自定义结果归并逻辑
        return mergeByCursor(resultSet);
    }
);

在实现分页方案时，我发现最容易被忽视的是边界条件的处理。比如当游标对应记录被删除时，简单的WHERE id < last_id会导致漏数据。我们的解决方案是引入LEFT JOIN + COALESCE组合：

sql复制SELECT t1.* FROM items t1
LEFT JOIN items t2 ON t2.id = #{lastId}
WHERE (t1.created_at < COALESCE(t2.created_at, NOW()) OR
      (t1.created_at = COALESCE(t2.created_at, NOW()) AND t1.id < COALESCE(t2.id, 0)))
ORDER BY t1.created_at DESC, t1.id DESC
LIMIT 10;

这种防御式编程虽然增加了复杂度，但能有效应对生产环境中的各种异常情况。