当前位置：首页 > news >正文

浅谈分页偏移量公式：为什么是 `(pageNum - 1) * pageSize`？

news 2025/11/12 13:04:54

前言

在开发 Web 应用或处理大量数据时，分页（Pagination） 是一个几乎无法绕开的核心功能。无论是用户列表、商品展示，还是日志查询，我们都需要将海量数据拆分成多个“页”来呈现，以提升性能与用户体验。

然而，许多初学者甚至有一定经验的开发者，在实现分页逻辑时，常常对这样一个公式感到困惑：

offset = (pageNum - 1) * pageSize;

为什么一定要减 1？为什么不能直接用 pageNum * pageSize？这个“-1”到底从何而来？

一、什么是分页？核心概念澄清

1.1 分页的基本组成

一个标准的分页系统通常包含以下参数：

参数名	含义	示例值
`pageNum`	当前请求的页码（从 1 开始）	3
`pageSize`	每页显示的记录数量	10
`offset`	跳过前面多少条记录（从 0 开始）	20
`total`	总记录数	150
`totalPages`	总页数	15

其中，offset 是连接“用户视角”与“系统底层”的桥梁。

1.2 用户视角 vs 系统视角

用户视角：人类习惯从 第 1 页 开始阅读，这是自然且直观的。
系统视角：计算机中的数组、列表、数据库行号等，索引均从 0 开始。

这种“起始点不一致”正是分页公式中需要 -1 的根本原因。

二、深入剖析：`(pageNum - 1) * pageSize` 的推导过程

2.1 场景设定

假设：

数据库中有 100 条用户记录。
每页显示 pageSize = 10 条。
用户点击“第 3 页”。

问题：应该从哪一条记录开始查询？

2.2 手动枚举验证

我们手动列出每页对应的数据范围（按数据库行索引，从 0 开始）：

页码（pageNum）	实际数据索引范围	起始索引（offset）
1	0 ~ 9	0
2	10 ~ 19	10
3	20 ~ 29	20
4	30 ~ 39	30
…	…	…

观察发现：

第 1 页 → offset = 0 = (1 - 1) × 10
第 2 页 → offset = 10 = (2 - 1) × 10
第 3 页 → offset = 20 = (3 - 1) × 10

规律成立！

2.3 数学归纳法证明

设：

n = pageNum（n ≥ 1）
s = pageSize（s > 0）

则第 n 页之前已经显示了 (n - 1) 整页，每页 s 条，共跳过：

$\text{offset} = (n - 1) \times s$

该值即为当前页第一条记录在整个数据集中的0 起始索引位置。

✅ 公式成立，逻辑自洽。

三、如果不减 1，会发生什么？

假设错误地使用：

offset = pageNum * pageSize; // 错误！

继续以上例（pageSize=10）：

页码	错误 offset	实际取到的数据	用户预期	结果
1	10	第 11~20 条	第 1~10 条	❌ 错位！
2	20	第 21~30 条	第 11~20 条	❌ 全错！
3	30	第 31~40 条	第 21~30 条	❌ 越错越远！

更严重的是：

第 1 页永远看不到开头数据。
如果总记录不足 pageSize，可能直接返回空结果，造成“数据丢失”的假象。

因此，漏掉 -1 是分页中最常见也最隐蔽的逻辑错误之一。

四、数据库层面的实现：SQL 中的 LIMIT / OFFSET

主流数据库（如 MySQL、PostgreSQL）支持通过 LIMIT 和 OFFSET 实现分页。

4.1 MySQL 示例

-- 查询第 3 页，每页 10 条
SELECT * FROM users
ORDER BY id
LIMIT 10 OFFSET 20;

其中：

LIMIT 10 表示最多取 10 条（即 pageSize）
OFFSET 20 表示跳过前 20 条（即 (3 - 1) * 10）

4.2 PostgreSQL / SQLite 语法类似

SELECT * FROM users
OFFSET 20 ROWS
FETCH NEXT 10 ROWS ONLY;

⚠️ 注意：OFFSET 值必须是非负整数，且通常需配合 ORDER BY 使用，否则结果顺序不确定。

五、编程语言中的分页实现

5.1 Java（Spring Boot + MyBatis）

int pageNum = 3;
int pageSize = 10;
int offset = (pageNum - 1) * pageSize;List<User> users = userMapper.selectByOffset(offset, pageSize);

Mapper XML:

<select id="selectByOffset" resultType="User">SELECT * FROM usersORDER BY idLIMIT #{pageSize} OFFSET #{offset}
</select>

5.2 Python（Django ORM）

Django 的 Paginator 内部自动处理了偏移计算：

from django.core.paginator import Paginatorpaginator = Paginator(User.objects.all(), 10)  # pageSize=10
page_obj = paginator.get_page(3)  # pageNum=3

其内部等价于：

offset = (3 - 1) * 10
users = User.objects.all()[offset : offset + 10]

5.3 JavaScript（前端分页模拟）

const data = [...]; // 假设有 100 条数据
const pageNum = 3;
const pageSize = 10;
const offset = (pageNum - 1) * pageSize;const currentPageData = data.slice(offset, offset + pageSize);

✅ 所有语言和框架，只要涉及“基于索引的切片”，都遵循同一套逻辑。

六、生活化类比：帮助理解

📖 类比 1：翻书

一本书每页印 10 行字。
你想看第 3 页。
那么你已经翻过了前 2 页（共 20 行）。
所以第 3 页的第 1 行，是全书的第 21 行（人类计数），但在程序中是索引 20（从 0 开始）。

🚌 类比 2：公交车座位

公交车每排 4 个座位，编号 0~3（第 1 排）、4~7（第 2 排）……
你被告知坐在“第 3 排”。
那你的座位号从 (3 - 1) * 4 = 8 开始（即 8,9,10,11）。

如果工作人员说“第 3 排从 12 号开始”，那你坐错了！

七、边界情况与注意事项

7.1 页码为 0 或负数？

规范做法：前端或后端应校验 pageNum >= 1。
若传入 pageNum = 0，(0 - 1) * pageSize = -10，导致 OFFSET -10，数据库报错。

✅ 建议：默认 pageNum = 1，并做参数合法性校验。

7.2 pageSize 为 0？

会导致除零错误或无限循环。
应限制 pageSize 在合理范围（如 1~100）。

7.3 总页数计算

总页数公式也需注意：

totalPages = (total + pageSize - 1) / pageSize; // 向上取整
// 或
totalPages = Math.ceil((double) total / pageSize);

例如：105 条数据，每页 10 条 → 共 11 页。

八、拓展话题：深度分页的性能问题

虽然 (pageNum - 1) * pageSize 在逻辑上完美，但当 pageNum 极大时（如第 10000 页），OFFSET 值会非常大（如 99990），数据库需要跳过前 99990 行再取 10 行，效率极低。

解决方案：

游标分页（Cursor-based Pagination）
基于上一页最后一条记录的 ID 或时间戳进行查询，避免 OFFSET。
```
SELECT * FROM users
WHERE id > last_seen_id
ORDER BY id
LIMIT 10;
```
限制最大页码
如只允许查看前 100 页，防止恶意请求。
使用覆盖索引优化
确保 ORDER BY 字段有索引，加速 OFFSET 扫描。

💡 这些属于进阶优化，但基础公式仍是所有分页逻辑的起点。

九、总结

问题	答案
为什么分页要用 `(pageNum - 1) * pageSize`？	因为用户页码从 1 开始，而数据索引从 0 开始，需将“第 n 页”转换为“跳过前 (n-1) 页的数据”。
不减 1 会怎样？	数据错位，第 1 页显示第 2 页内容，严重时导致数据不可见。
这个公式适用于哪些场景？	所有基于偏移量（OFFSET）的分页系统，包括 SQL 查询、数组切片、列表分页等。
是否有替代方案？	有，如游标分页，但基础公式仍是理解分页机制的基石。

十、附录：常见误区澄清

误区	正确理解
“页码应该从 0 开始”	用户体验要求从 1 开始；技术实现可内部转换，但对外 API 应保持 1 起始。
“直接用 pageNum * pageSize 更简单”	逻辑错误，会导致数据偏移。
“数据库 OFFSET 很快，不用优化”	大偏移量下性能急剧下降，需警惕。