我先给结论，再说明它在项目里解决什么问题。从 OFFSET 扫描、回表成本和游标分页设计高性能翻页查询。LIMIT offset, size 的 offset 很大时，MySQL 通常仍要扫描 offset + size 条记录并丢弃前面部分；若排序或筛选不能由覆盖索引完成，还会产生大量回表。连续翻页优先使用基于稳定排序键的游标分页。 例如按 (createdat, id) 倒序，下一页带上上一页最后一条的两个值，用小于条件继续查询，复杂度不再随页码线性增长。

核心机制我会按一次真实执行过程来讲。沿着「接收页码与排序 → 索引扫描跳过 offset → 逐行回表或过滤 → 取 limit 条记录 → 返回下一页定位信息」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 接收页码与排序 LIMIT offset,limit 需要找到并丢弃前 offset 行，页码越深工作量线性增长。 索引扫描跳过 offset 若排序索引不覆盖返回列，跳过的每行仍可能回表，I/O 放大更严重。

实现细节只抓关键入口，不会整段背源码。handlerreadnext：顺序扫描行计数。 EXPLAIN ANALYZE：offset 丢弃行的真实工作量。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。对 offset 0/10万/100万与游标分页画延迟曲线，并在并发插入下核对重复遗漏。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「扫描/返回」为主基线，记录值应满足「游标接近 1」；同时保存 rows examined/returned、回表次数，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。导出按页码每次 offset 增加 1000，到后期单页扫描数百万行。改为按 (createdat,id) 复合游标推进，并记录检查点后，单批成本稳定且可断点续跑。 只用非唯一时间字段做游标导致遗漏：rows examined/returned：使用复合唯一游标。 深分页加缓存仍计算昂贵：回表次数：全量导出改异步检查点。 方案：更适合的场景：主要收益：代价与边界。 offset 分页：浅页、允许随机跳页：接口简单、总数展示自然：深页线性变慢且并发变更会漂移。 Keyset 游标：顺序翻页与无限滚动：性能稳定、重复遗漏少：不能自然随机跳页。 异步导出：全量或超大结果集：隔离在线请求、可断点：结果延迟且需任务治理。 选型至少带上 数据规模、选择性、读写比、事务长度和峰值并发，并用上面的量化基线验证；未知数据应明确为待测假设。