前言

在后端开发中，分页查询是最基础且高频的需求，常见于APP信息流、消息列表、后台管理页面、日志查询等场景。绝大多数开发者入门最先接触的都是 LIMIT OFFSET 传统分页，但在大数据量、深度分页场景下，该方案会出现严重的性能雪崩、数据错乱等问题。

而 游标分页（Cursor分页）是互联网大厂主流的分页方案，完美解决了传统分页的核心痛点，广泛应用于抖音、小红书、微博等信息流业务。本文将结构化讲解游标分页的核心原理、实现方案、游标字段选型、与传统分页对比、适用场景及避坑点，帮助你彻底掌握企业级分页方案。

传统分页基于 数据偏移量实现，核心逻辑是：从数据表起始位置，跳过指定 offset 条数据，再读取 limit 条数据。

-- 传统分页SQL：第1001页，每页10条
 SELECT * FROM user ORDER BY id LIMIT 10 OFFSET 10000;

• 深度分页性能极差MySQL 执行该语句时，会先扫描 offset+limit 条数据，丢弃前 offset 条，仅返回最后 limit 条。页码越深，扫描的数据量越大，索引遍历、回表次数成倍增加，数据量过万后查询耗时急剧飙升，出现性能雪崩。
• 分页数据错乱（漏数据、重复数据）分页过程中，如果表头有新增、删除数据，整体数据顺序会发生偏移：新增数据会导致旧数据后移，下一页漏数据；删除数据会导致旧数据前移，下一页重复加载数据，数据一致性极差。

游标分页彻底抛弃了「偏移量跳过数据」的逻辑，采用 唯一有序标记定位边界的思想，从底层解决了传统分页的缺陷。

游标分页：通过上一页最后一条数据的 全局有序、唯一字段（游标），作为下一页数据的查询起点，通过 WHERE 条件直接定位分页起始位置，无需扫描前置历史数据。

1. 首页：无游标，直接查询固定条数数据；
2. 翻页：前端携带上一页末尾的游标参数，后端通过 WHERE 条件过滤，直接读取游标之后的数据；
3. 循环往复，实现稳定翻页。

-- 首页查询 
SELECT * FROM user ORDER BY id LIMIT 10; 
-- 下一页（上一页最后一条id=10000） 
SELECT * FROM user WHERE id > 10000 ORDER BY id LIMIT 10;

底层优势：依托B+树索引直接定位游标位置， 无论第几页，仅扫描limit条数据，性能全程稳定。

游标分页基于 绝对数据边界分割页面，游标生成后，游标之前的所有数据新增、删除、修改，都不会影响当前分页区间，彻底解决漏数据、重复数据问题。

游标字段必须满足： 全局有序 + 唯一不重复。单一字段无法满足唯一性时，需使用「有序字段+唯一主键」复合游标。

适用于简单排序场景，字段本身同时满足有序、唯一：

• 自增ID：最高效，适合简单列表分页
• 雪花ID：分布式系统首选，适配分库分表
• UUIDv7：基于时间有序生成
• 业务流水号：如订单号、支付单号（时间+序列规则）

大多数业务排序字段（时间、热度分数）存在大量重复值，需拼接唯一ID兜底，保证分页边界精准。

• 时间戳+ID（Feed流标准方案）朋友圈、消息列表、动态资讯（按时间倒序）。同一秒多条数据，仅用时间戳会漏数据，必须组合ID。

-- 复合游标查询SQL 
SELECT * FROM post WHERE (create_time < '2024-01-01 12:00:00') OR (create_time = '2024-01-01 12:00:00' AND id < 100) ORDER BY create_time DESC, id DESC LIMIT 10;

配套联合索引：idx_create_time_id (create_time, id)。

• 热度分数+ID（榜单场景）热门榜单、点赞排行、积分排名。分数相同，通过ID区分重复排序数据。
• 自定义排序值+ID后台自定义排序列表，运营配置的sort_num可重复，组合ID实现稳定分页。

• 无序UUID（v1/v4）
• 纯时间戳
• 状态、分类、标签字段
• 浮点数分数

企业级项目会对复合游标进行 Base64编码封装，统一前后端交互。

1. 首页查询数据，提取最后一条数据的时间、ID；
2. 后端拼接游标信息并Base64加密，生成唯一游标字符串返回前端；
3. 前端下拉加载，原样回传游标字符串；
4. 后端解码拆分参数，拼接复合查询SQL，实现分页。

import java.util.Base64;
import java.time.LocalDateTime;
// 游标编码：后端传给前端
public String encodeCursor(LocalDateTime time, Long id)
{
    String raw = time + "," + id;
    return Base64.getEncoder().encodeToString(raw.getBytes());
}

// 游标解码：前端回传，后端解析
public Object[] decodeCursor(String cursorStr)
{
    byte[] decode = Base64.getDecoder().decode(cursorStr);
    String[] parts = new String(decode).split(",");
    LocalDateTime time = LocalDateTime.parse(parts[0]);
    Long id = Long.parseLong(parts[1]);
    return new Object[]{time, id};
}

摒弃pageNum、pageSize，采用游标专属返回格式，适配无限滚动：

{
  "code": 200,
  "data": [],
  "paging": {
    "next_cursor": "MTcyMDAwMDAwMDAwLDExMA==",
    "has_more": true
  }
}

对比维度	传统Limit OFFSET分页	游标Cursor分页
核心原理	偏移量跳过前置数据	唯一游标定位分页边界
深度分页性能	越往后越慢，性能雪崩	全程稳定，无性能衰减
数据一致性	差，易漏数据、重复数据	优，游标前数据变动不影响分页
随机跳页	支持，可直达任意页码	不支持，仅支持上下翻页
总条数/总页数	天然支持	需额外COUNT查询
实现难度	简单，框架原生支持	较复杂，需处理复合游标、编码
适用场景	后台管理系统、小数据列表	信息流、大数据量、无限滚动列表

• APP/小程序信息流：朋友圈、短视频、资讯、小红书动态（无限下拉加载）
• 消息聊天列表：私信、群聊、系统通知，按时间浏览历史数据
• 大数据量长列表：千万级数据表、订单流水、操作日志、浏览记录
• 各类热度榜单：点赞排行、积分榜单、热门商品列表
• ES大数据检索：使用search_after替代Scroll，实现高性能深度分页
• 分布式分库分表：无全局偏移量，游标分页性能碾压传统分页

• 后台管理系统：需要手动输入页码、随机跳页
• 需要展示总条数、总页数统计的页面
• 频繁双向快速翻页的业务
• 无唯一有序字段的复杂多维度排序场景

• 传统分页胜在实现简单、支持跳页，但深度分页性能差、数据不稳定，仅适合后台小数据场景。
• 游标分页胜在性能稳定、数据精准，是互联网大数据分页的最优解，唯一短板是不支持随机跳页。
• 业务开发中，简单排序用单游标，时间/热度排序必须用复合游标+联合索引，工程化场景统一Base64编码封装。