求解深分页问题,last pk适合什么情况

在 MySQL 中，“深分页”是一个非常头疼的问题。当我们执行LIMIT 1000000, 10时，数据库并不是直接跳到第 100 万行，而是扫描前 1,000,010 行，然后扔掉前 1,000,000 行。这会导致大量的随机 I/O 和回表操作，性能极差。

你提到的last pk（上一次主键 ID）方案，也就是业内常说的“滚动分页”或“寻路法（Seek Method）”。

1. 核心逻辑

这种方案的本质是：利用索引的有序性，直接定位到下一页的起点。

• 普通分页：SELECT * FROM table WHERE ... LIMIT 1000000, 10;（慢，扫描 100 万行）
• last pk 分页：SELECT * FROM table WHERE id > 1000000 LIMIT 10;（快，直接从 ID=1000000 处开始扫描）

2. last pk 适合什么情况？

这个方案虽然快，但它对业务场景有比较严格的要求：

A. 适合“下一页”模式（流式展示）

这是它最完美的应用场景。比如：

• 社交媒体信息流：抖音、微博、朋友圈。你只会不停地往下滑，而不会突然跳到第 100 页。
• 实时日志查看：按照时间顺序（或自增 ID）一条条加载。

B. 适合大数据量的全表扫描/数据迁移

• 如果你需要把几亿条数据从 MySQL 抽取到 ElasticSearch 或者进行 ETL 处理，用LIMIT offset会越跑越慢，甚至拖垮数据库。
• 使用WHERE id > last_id可以保证整个抽取过程的响应时间是平稳的。

C. 适合排序字段是主键或有唯一索引的场景

• 因为它是基于“上一个 ID”来寻路的，如果排序字段不是 ID（比如按“修改时间”排序），且时间有大量重复，逻辑就会变得复杂（需要WHERE (time < last_time) OR (time = last_time AND id < last_id)）。

3. last pk 的局限性（不适合的情况）

1. 不适合“跳页”查询：

• 如果你要求用户能直接点击“第 500 页”，这种方案就瞎了。因为你没法在不扫描的情况下知道第 499 页的最后一个 ID 是多少。

2. 主键必须有序（或排序字段稳定）：

• 如果数据频繁删除导致 ID 极其不连续，虽然不影响性能，但在某些需要精确计算步长的业务场景下可能会有小麻烦。

4. 补充：如果必须要“跳页”怎么办？

如果业务强制要求深分页且必须支持跳页，通常有两种折中方案：

• 方案一：延迟关联（Deferred Join）
  先通过覆盖索引只查找主键，减少回表。

SELECT*FROMtablet1INNERJOIN(SELECTidFROMtableWHERE...LIMIT1000000,10)t2ONt1.id=t2.id;

在二级索引树里面遍历索引树找id,跳过签100万个id返回10个id,然后10个id再联表查询

原理：在内查询里只走索引不回表，等确定了这 10 个 ID 后再回表，效率提升巨大。

• 方案二：限制最大翻页数
  这也是大厂常用的办法（如百度、谷歌、京东）。你会发现它们通常只让你翻到 100 页左右，后面的数据就不给看了。

总结

last pk 是解决深分页性能问题的“银弹”，但它牺牲了“自由跳页”的功能。如果你的场景是瀑布流、滚动加载或批量数据处理，请务必使用last pk方案。

你现在的业务场景是属于用户侧的列表展示，还是后台的数据处理任务？