分页查询存在什么问题，如何改进

传统的分页查询通常依赖于 LIMIT 和 OFFSET（或类似的机制）来实现。客户端请求特定的页码和每页的数据量，服务器据此计算出偏移量（OFFSET）来跳过相应数量的数据。尽管实现简单，但这种方式在处理大规模数据集时会暴露出一系列问题：

深度分页性能下降：当用户请求的页码非常靠后时（即深度分页），数据库需要扫描并跳过大量的记录才能到达指定的偏移位置，这会导致查询时间随着页码的增加而线性增长，极大地消耗数据库资源。
数据不一致：在用户浏览分页数据的过程中，如果数据库中的数据发生增删操作，会导致后续页面的数据出现重复或遗漏。例如，如果在用户加载第二页之前，第一页的数据被删除或有新数据插入，那么第二页的起始点就会发生漂移。
资源消耗大：即使只是为了跳过，数据库仍然需要加载大量中间数据到内存中，这会增加CPU和内存的负载，尤其是在高并发的深度分页场景下，可能会拖垮数据库。

为了克服传统分页的弊端，基于游标的分页（Cursor-based Pagination），也常被称为“键集分页”（Keyset Pagination），提供了一种更为高效和稳健的解决方案。

基于游标的分页不使用页码和偏移量，而是依赖于一个“游标”（Cursor）来定位数据。这个游标本质上是一个指向上一页最后一条记录的唯一标识符或锚点。当客户端请求下一页数据时，它会带上这个游标，服务器的查询语句则会利用这个游标作为起点，获取紧随其后的N条记录。

这个游标通常是数据表中一个具有唯一性且有序的列，例如自增ID、时间戳，或者是多个列的组合。

其核心思想是将 OFFSET 查询转化为一个高效的 WHERE 条件查询。

假设我们有一个按 created_at 降序排列的订单表，每页显示10条记录。

传统分页查询（第二页）： sql SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 10; 这条查询会先排序，然后跳过前10条，再取10条。
基于游标的分页查询（第二页）：
1. 第一次查询：获取第一页数据，并记录下最后一条数据的 created_at 值（例如 2025-09-01 10:00:00）作为下一页的游标。
2. 第二次查询：客户端请求下一页时，将该游标传递给服务器。 sql SELECT * FROM orders WHERE created_at < '2025-09-01 10:00:00' ORDER BY created_at DESC LIMIT 10; 这条查询直接从上一次结束的位置开始查找，避免了扫描和跳过大量无关数据。

处理非唯一游标：如果作为游标的列（如 created_at）可能存在重复值，可以组合一个唯一的列（如 id）来创建复合游标，确保分页的准确性。

SELECT * FROM orders WHERE (created_at, id) < ('2025-09-01 10:00:00', 12345) ORDER BY created_at DESC, id DESC LIMIT 10;