在做列表接口时很多人先写出这句：

SELECT id。title,created_at
FROM article
ORDER BY created_at DESC
LIMIT?,，;

数据少的时候没毛病。数据一多，使用者偶尔会在第二页看到第一页的记录。或者有一条怎么翻都翻不到。怎么说呢，

这事经常被一句“深分页慢”带过去。其实是两个不同的坑：排序不稳定，还有翻页期间数据发生了变化。只调整 OFFSET 的扫描量，修不好前一个；老实说，只在排序后补主键，也修不好后一个。其实，

相同时间的记录。谁排前面没有保证

假设文章表里有三条数据的 created_at 都是同一时间。SQL 只要求按时间倒序，并没有规定这三条内部怎么排。

MySQL 的官方手册写得很直白：如果多行的 ORDER BY 列值相同，服务端可以按任意顺序返回它们；执行计划变化时这个顺序也可能变化。LIMIT 本身就可能影响执行计划。

这不是数据库“偶尔抽风”。不过，查询写出来的顺序本来就不完整。

先把排序补成唯一的：

SELECT id。title,created_at
FROM article
ORDER BY created_at DESC,id DESC
LIMIT?,，;

只要 id 唯一，任何两行都能分出先后。说起来，这里还有个小细节：两个字段必须保持同一套方向。时间倒序、同一时间下 id 也倒序，后面的游标条件才能原样对上。

补了 id，为什么还会重复

第一页刚查完。顺序是：

1 | 2024-08-13 10:00:00 | ...
2 | 2024-08-13 09:58:00 | ...
3 | 2024-08-13 09:55:00 | ...
...

页面大小为 10 条，客户端拿到了前十条。

这时新文章插到最前面。第二页继续执行 LIMIT + OFFSET 时数据库看到的顺序已经成了：

0 | 2024-08-13 10:01:00 | ... -- 新增
1 | 2024-08-13 10:00:00 | ... -- 原第一页第一条
2 | 2024-08-13 09:58:00 | ...
...

跳过前两行以后第二页返回第3~12 条，其中原第一页第一条被重复出现。 删除或更新排序字段时一样可能漏行。

接口不要求跳页时我会改成复合游标

第一页仍然这样查：

SELECT id。title,created_at
FROM article
ORDER BY created_at DESC,id DESC
LIMIT?，说起来，

返回数据时把最终一条的 created_at 和 id 一起交给客户端。例如最终一条是：

created_at = '2024-08-13 09:55:00'
id = 42

下一页从这个位置之后继续：

SELECT id。title,created_at
FROM article
WHERE
OR
ORDER BY created_at DESC,id DESC
LIMIT?，

为什么不能只传时间？老实说，

• 时间会重复。只用 created\_at < ? 会直接漏掉同一秒里排在后面的记录。
• 游标、WHERE 条件、ORDER BY 三处都得是同一组字段。
• MySQL 可以配对应的降序复合索引：
• 这样查询可以沿着索引从游标位置继续向后读，不必每一页都从头数到 OFFSET。实际有没有用到，还要看 EXPLAIN；别看见建了索引就默认调整器一定选它。
• 如果你想进一步减少扫描，可以考虑使用覆盖索引来避免回表操作。
• 注意。如果有人频繁地插入或删除新文章，你仍需要定期维护索引以保持性能稳定。
• # 面试技巧: 回答 MySQL 分页问题时要先问排序键是否唯一。再问翻页期间是否有并发写入，接下来再谈扫描成本与索引选择。这三个问题决定 SQL 的写法与执行计划差异很大。

游标分页也不是“绝对不漏”

• 它解决的是最常见的滚动列表：使用者往下翻时头部不断有新数据进来。新行排在游标前面不会把已经读过的行挤进下一页。
• 但如果翻页期间有人修改了旧记录的 created\_at,它可能跨过游标；说起来，记录被删除后也不可能继续返回。导出、对账这类要求严格一致的数据任务。应固定快照或先固化待导出的主键集合，而不能把在线列表接口硬当作快照使用。

还有一个取舍

• 游标分页很适合“下一页”和无限滚动，但不擅长直接跳到第 N  页。按理说，如果产品真需要随机跳转。就得接受 OFFSET 的成本或另做页面编号到锚点映射方案。

---