偏移分页 vs 滚动分页
原创
偏移分页 vs 滚动分页：学习笔记与思考
最近在学习分页技术，发现偏移分页和滚动分页是两种完全不同的思路。记录一下我的理解和思考。
什么是偏移分页？
偏移分页就是我们最常见的分页方式，通过页码来翻页。
实现原理：
-- 第1页：跳过0条，取10条
SELECT * FROM users LIMIT 10 OFFSET 0;
-- 第2页：跳过10条，取10条
SELECT * FROM users LIMIT 10 OFFSET 10;
-- 第3页：跳过20条，取10条
SELECT * FROM users LIMIT 10 OFFSET 20;页面效果：
[上一页] [1] [2] [3] [4] [5] [下一页]用户可以直接跳到任意页码，很灵活。
什么是滚动分页？
滚动分页就像微博、朋友圈那样，往下滑就自动加载更多内容。
实现原理：
-- 第一次加载：从ID最大的开始取
SELECT * FROM users ORDER BY id DESC LIMIT 10;
-- 加载更多：从上次最小的ID继续取
SELECT * FROM users WHERE id < 1050 ORDER BY id DESC LIMIT 10;
-- 再加载更多：继续往前取
SELECT * FROM users WHERE id < 1040 ORDER BY id DESC LIMIT 10;页面效果：
[已有内容]
[新加载的内容]
[加载更多按钮] 或者 [自动加载]用户只能往下滚动，不能跳页。
两种方式的对比
用户体验
偏移分页：
- ✅ 可以跳到任意页，导航清晰
- ✅ 适合搜索结果浏览
- ❌ 需要点击翻页，操作多一步
滚动分页：
- ✅ 连续浏览体验好，像在看一个长列表
- ✅ 移动端友好，滑动很自然
- ❌ 不能快速跳到后面的内容
性能表现
偏移分页的问题：
-- 翻到第1000页时
SELECT * FROM users LIMIT 10 OFFSET 9990;数据库是怎么"跳过"的？
实际上数据库不是真的"数数跳过"，而是这样处理的：
- 如果有索引：
- 数据库扫描索引，找到第9991条记录的位置
- 就像翻书找第9991页，需要一页页翻过去
- 即使有索引，也要"走过"前面9990条记录的索引项
- 如果没有索引：
- 更惨，需要全表扫描
- 从第1条开始读，一直读到第9990条，然后丢弃
- 再读第9991到第10000条返回给用户
为什么越往后越慢？
第1页：OFFSET 0 → 直接开始取数据，很快
第10页：OFFSET 90 → 需要跳过90条，稍慢
第100页：OFFSET 990 → 需要跳过990条，明显慢了
第1000页：OFFSET 9990 → 需要跳过9990条，巨慢！就像你要找一本厚书的第800页，即使你知道页码，也得从前面翻过去，不能直接跳到第800页。
页数越大越慢！
滚动分页的优势：
-- 不管加载多少次，都是这样
SELECT * FROM users WHERE id < 某个值 ORDER BY id DESC LIMIT 10;每次都是直接定位，不需要跳过前面的数据，速度稳定。
数据一致性
偏移分页的困扰： 假设用户在看第2页，这时有新数据插入到第1页：
- 原来第1页的最后一条数据，被挤到了第2页的第一条
- 用户会看到重复的数据！
滚动分页的稳定性： 因为是基于ID或时间戳来分页，新插入的数据不会影响已经加载的内容。
实际应用场景
适合偏移分页的场景：
- 搜索结果页面 - 用户需要浏览和比较不同页的结果
- 后台管理系统 - 需要精确导航到某一页
- 电商商品列表 - 用户可能想跳到最后几页看看
例子：
- Google搜索结果
- 淘宝商品列表
- 管理后台的用户列表
适合滚动分页的场景：
- 社交媒体信息流 - 用户习惯连续浏览
- 新闻资讯类 - 内容按时间排序，越新越重要
- 移动端应用 - 滑动操作更自然
例子：
- 微博、微信朋友圈
- 抖音、快手视频流
- 知乎回答列表
技术实现要点
偏移分页的优化
问题： OFFSET太大时性能差
解决方案：
-- 不要用OFFSET，改用WHERE条件
-- 假设上一页最后一条记录的ID是100
SELECT * FROM users WHERE id > 100 ORDER BY id LIMIT 10;但这样就失去了"跳页"的能力。
滚动分页的实现细节
关键点：
- 选择合适的游标字段（通常是ID或创建时间）
- 游标字段必须有索引，且值要唯一递增
- 前端需要记录当前的游标值
代码示例：
// 前端记录游标
let lastId = null;
function loadMore() {
const url = lastId
? `/api/users?lastId=${lastId}&limit=10`
: `/api/users?limit=10`;
fetch(url).then(response => {
const users = response.data;
if (users.length > 0) {
lastId = users[users.length - 1].id;
}
// 追加到页面
appendUsers(users);
});
}我的思考和总结
选择原则
什么时候用偏移分页：
- 数据量不是特别大（几十万条以内）
- 用户需要随意跳页
- 数据相对稳定，不频繁增删
什么时候用滚动分页：
- 数据量很大
- 数据经常有新增（如社交媒体）
- 移动端为主
- 用户主要是顺序浏览
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
