MySQL 第几万页开始变慢：用稳定排序和游标条件替代深 OFFSET

如果接口已经翻到第几万页，LIMIT 20 OFFSET 400000 仍然要先找到并丢弃前面的记录，页大小很小并不代表扫描量很小。更稳妥的做法是先把排序补成确定顺序，再把“从哪里继续”编码成上一页最后一行的游标条件。

下面用 orders 表说明。假设列表按 created_at DESC 展示，id 是唯一主键。MySQL 官方文档也提醒：当 ORDER BY 的值相同时，未参与排序的列顺序是不确定的，LIMIT 还可能影响执行计划。因此性能和一致性要一起处理。

为什么深 OFFSET 会把第几万页变成扫描题

传统写法把页码换算成偏移量：

SELECT id, created_at, total_amount
FROM orders
WHERE user_id = 17
ORDER BY created_at DESC, id DESC
LIMIT 20 OFFSET 400000;

服务器仍要处理满足条件的前 400020 行，最后只返回其中 20 行；当排序不能完全借助索引时，还可能发生更大的排序工作。这个查询适合浅页或确实要跳到某个页码的场景，但不适合无限滚动和导出式逐页读取。

先把排序键补成稳定的联合顺序

只写 ORDER BY created_at DESC 不够：同一秒写入的多条订单拥有相同时间，数据库可以用不同执行计划返回不同的相对顺序。分页时，这会表现为重复或漏掉记录。

把唯一键补到排序末尾：

ORDER BY created_at DESC, id DESC

然后让过滤、排序和取数尽量共享索引，例如可以评估：

CREATE INDEX idx_orders_user_created_id
ON orders (user_id, created_at DESC, id DESC);

索引不是看到建表语句就算完成。数据分布、查询列和版本都会影响计划，最终要用 EXPLAIN 看过滤条件是否接住索引、是否出现额外排序，以及估算行数是否明显随页码增长。

用游标条件改写下一页查询

第一页仍可直接取 20 行。接口返回最后一行的 created_at 和 id，下一页用“时间更早，或时间相同但 id 更小”的边界：

SELECT id, created_at, total_amount
FROM orders
WHERE user_id = 17
  AND (created_at 

这个条件表达的不是“第几页”，而是“从哪一行之后继续”。游标应由服务端编码并签名，至少绑定查询过滤条件、排序方向和两个边界值，避免客户端篡改后得到另一套结果。若排序是升序，比较符号要整体反过来。

用 EXPLAIN 和接口边界确认改造结果

改造前后分别执行 EXPLAIN，重点看访问类型、使用的 key、估算 rows、Extra 中是否出现额外排序或回表。不要用一台空库的一次计划宣称固定收益；应在接近生产的数据量和真实过滤条件下观察。

接口层也要明确三个边界：游标为空时取第一页；结果少于页大小时结束；数据在两次请求间插入或删除时，游标保证的是按既定顺序继续读取，不保证“总数”和页面内容永远静止。需要总页数、随机跳页或用户频繁回到第 N 页时，仍可保留 OFFSET，或另做面向搜索的定位方案。

相关问题

时间字段不唯一怎么办？ 始终追加唯一且方向一致的键；如果没有合适的键，先补充稳定的业务序列。

游标分页能跳到第 100 页吗？ 它天然优化连续翻页，不能像 OFFSET 一样直接定位任意页；产品需要跳页时要接受额外定位成本。

为什么改成游标后还是慢？ 先确认 WHERE、ORDER BY 与联合索引前缀匹配，再看是否有复杂表达式、低选择性过滤或必须回表的大字段。

参考：MySQL 8.4 LIMIT Query Optimization。