列表深分页到底该用 offset、游标还是延迟关联？聊聊各自的取舍

先说背景。我做了 10 年数据工程，最近帮两个团队看"列表页越翻越慢"的问题，发现大家对"深分页怎么解"几乎没有共识：有人直接 LIMIT 100000, 20，有人上 WHERE id > last_id 的游标，还有人写 JOIN 派生表 做延迟关联。三种方案各有拥趸，但很少有人把取舍摊开讲清楚。

常见分歧大致是这几种做法：

1. offset 分页（LIMIT offset, size）：实现最简单，前端体验最自然——能"跳到第 N 页"、能随机回退。但代价是数据库必须扫描并丢弃前 offset 行，数据量一大（千万级 + 二级索引）P99 就崩，且并发写入时还会出现"翻页丢行 / 重复行"。
2. 游标分页（seek / keyset，WHERE created_at < :last AND id < :last_id）：性能稳，O(1) 不随页码劣化，对大表友好。代价是只能"下一页"，跳页 / 随机回退不友好，排序列必须稳定且可索引，多列排序时游标要带全部排序键。
3. 延迟关联 / 派生表（先在索引子查询里取 id，再回表 JOIN）：折中方案，能在一定程度上减少回表开销，但写法易踩坑（子查询被物化、索引选错反而更慢），优化器行为在不同 MySQL 版本上并不一致，维护成本高。

我的倾向：绝大多数"用户翻列表"场景，默认游标分页，把 offset 只留给"必须支持跳页"的后台管理 / 导出类场景，并配合 id 单调主键做兜底。理由有三：一是深分页的性能问题本质是"扫描量随页码线性增长"，游标是唯一天然规避它的方案；二是用户体验上，绝大多数 C 端 / B 端列表是"顺序往下刷"，跳页是伪需求，为它付出 O(offset) 的代价不值；三是延迟关联看着优雅，实则把调优风险转嫁给了优化器和 DBA，长期看是负债。

想听大家聊聊：

• 你们线上"必须支持跳页 / 随机定位"的场景，最后是怎么扛住性能压力的？有没有 offset 之外的干净解法？
• 多条件排序（比如"按热度、同分按时间"）的游标，你们怎么设计排序键？遇到并列值漏行 / 重复怎么处理？
• 游标分页对"新数据不断插入"导致的翻页抖动，你们接受吗？还是用时间戳快照冻结？

抛砖引玉，欢迎拿你们真实的表规模、QPS、MySQL / PG 版本来对方案，空谈取舍没意义。