在数据驱动的应用中,当需要从海量数据表中获取数据时，一次性将所有记录加载到前端不仅会造成巨大的性能瓶颈，也会严重影响用户体验，分页查询成为了数据库操作中一项至关重要的技术，它允许每次只获取一小部分数据，用户可以通过“上一页”、“下一页”或页码导航来浏览全部内容。
最基础的实现：LIMIT 和 OFFSET
绝大多数关系型数据库,如MySQL、PostgreSQL、SQLite等，都通过LIMIT和OFFSET子句来支持分页，这是最直观、最简单的实现方式。
LIMIT：指定每页需要返回的最大记录数。OFFSET：指定在开始返回记录之前需要跳过的记录数。
其基本语法如下：
SELECT column1, column2, ... FROM table_name LIMIT [每页数量] OFFSET [跳过的记录数];
要查询articles表中的数据，每页显示10条，获取第3页的数据（即第21到30条记录），SQL语句如下：
SELECT * FROM articles ORDER BY publish_date DESC LIMIT 10 OFFSET 20;
这里,OFFSET 20告诉数据库先跳过前20条记录，然后LIMIT 10从第21条记录开始返回10条。
LIMIT/OFFSET的性能陷阱
虽然LIMIT/OFFSET简单易用，但在处理大数据量时，它存在一个严重的性能问题，当OFFSET的值变得非常大时（OFFSET 100000），查询速度会急剧下降。
原因在于,数据库并非直接“跳到”第100001条记录，相反，它必须从表的开头（或索引的开头）扫描并获取前100000条记录，然后将这些记录全部丢弃，最后才返回你需要的记录，这个过程会随着OFFSET值的增大而变得愈发低效，消耗大量的CPU和I/O资源。
高效的替代方案：键集分页
为了解决OFFSET的性能问题，业界普遍采用一种更高效的策略——键集分页，也常被称为游标分页，它的核心思想是：不记录要跳过多少条，而是记住上一页最后一条记录的唯一标识（通常是主键ID或带有索引的时间戳）。
下一页的查询将基于这个“游标”来获取数据，假设我们有一个自增主键id，获取第一页数据的SQL很简单：
SELECT * FROM articles ORDER BY id ASC LIMIT 10;
当获取第一页数据后,我们记下最后一条记录的id，比如是123，获取下一页的SQL就变成了：
SELECT * FROM articles WHERE id > 123 ORDER BY id ASC LIMIT 10;
这种方式的巨大优势在于,数据库可以利用id列上的索引直接定位到id > 123的起始位置，无需扫描和丢弃任何记录，无论数据量有多大，查询速度都能保持稳定和高效。
键集分页也有其局限性：它不支持随机跳页（如直接跳转到第5页），只支持“上一页”和“下一页”的连续翻页模式，对于大多数现代应用（如社交媒体信息流），这完全是可以接受的。
分页方案对比
下表清晰地对比了两种主流分页方案的特点：
| 特性 | LIMIT/OFFSET 分页 |
键集分页 |
|---|---|---|
| 原理 | 跳过N条记录，返回M条 | 记录上一页最后一条记录的标识，获取大于该标识的M条记录 |
| 优点 | 实现简单，支持随机跳页 | 性能极高，尤其在深分页时，性能稳定 |
| 缺点 | 深分页时性能急剧下降 | 无法实现随机跳页，逻辑相对复杂 |
| 适用场景 | 数据量小，或需要随机跳页的场景 | 数据量大，无限滚动或仅支持“上一/下一页”的场景 |
相关问答FAQs
Q1：为什么我使用OFFSET分页，翻到后面几页时页面加载得特别慢？
A1： 这正是OFFSET分页的固有性能缺陷，当您请求第N页时，数据库需要计算并丢弃(N-1) * 每页数量条记录，请求第1000页（每页10条），数据库必须先找到并丢弃前9990条记录，然后才能返回您需要的10条，这个“丢弃”的过程非常耗时，并且随着页码增加而线性变长，导致页面加载缓慢，解决方法是改用键集分页。
Q2：分页查询和数据库索引有什么关系？
A2： 关系非常密切，无论是哪种分页方式，索引都是性能的关键，对于LIMIT/OFFSET，ORDER BY子句后面的列建立索引可以加速排序和定位，对于键集分页，作为“游标”的列（如id或created_at）必须建立索引，否则数据库无法快速定位到起始点，分页的优势将荡然无存，性能甚至可能比OFFSET更差，正确的索引是高效分页的基石。