数据库分页查询怎么实现才最高效？如何避免深分页的性能陷阱？

在数据驱动的应用中,当需要从海量数据表中获取数据时，一次性将所有记录加载到前端不仅会造成巨大的性能瓶颈，也会严重影响用户体验，分页查询成为了数据库操作中一项至关重要的技术，它允许每次只获取一小部分数据，用户可以通过“上一页”、“下一页”或页码导航来浏览全部内容。

最基础的实现：`LIMIT` 和 `OFFSET`

绝大多数关系型数据库,如MySQL、PostgreSQL、SQLite等，都通过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简单易用，但在处理大数据量时，它存在一个严重的性能问题，当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条记录
优点	实现简单，支持随机跳页	性能极高，尤其在深分页时，性能稳定
缺点	深分页时性能急剧下降	无法实现随机跳页，逻辑相对复杂
适用场景	数据量小，或需要随机跳页的场景	数据量大，无限滚动或仅支持“上一/下一页”的场景