偏移量分页在大数据量下变慢是因为数据库每次需从头扫描并跳过OFFSET行，如查第1000页（OFFSET 99999）需丢弃近10万行，导致IO和CPU开销陡增。
偏移量分页（OFFSET/LIMIT）为什么在大数据量下变慢
因为数据库每次都要从头扫描，跳过前 OFFSET 行再取数据。100 万条记录查第 1000 页（OFFSET 99999），MySQL 可能要先定位并丢弃近 10 万行，IO 和 CPU 开销陡增。
常见错误现象：SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 200000 响应从 20ms 涨到 2s+，且越往后越慢。
- 适用场景：数据量小（
-
ORDER BY字段必须有索引，否则OFFSET会触发全表扫描 - PostgreSQL 对大
OFFSET有优化（如cursor_tuple_fraction），但 MySQL 几乎无缓解手段 - 不要用
COUNT(*)做总页数——用户根本不需要知道“共 5032 页”，反而拖垮接口
游标分页（Cursor-based）怎么写才真正安全
核心是用上一页最后一条记录的排序字段值（比如 created_at 和 id）作为下一页起点，避免跳行计算。
典型错误写法：WHERE created_at —— 如果同一秒有多条记录，会漏或重。
立即学习“Python免费学习笔记（深入）”；
- 必须组合唯一性字段：例如
WHERE (created_at, id) （降序时用 ） - 排序字段顺序必须和
WHERE中一致，且所有字段都需有联合索引，例如INDEX(created_at, id) - 游标值要 Base64 编码后传给前端（避免 JSON 中时间格式歧义或特殊字符问题），后端解码后直接拼进 SQL
- 首次请求没有游标？用
WHERE (created_at, id) 这类兜底逻辑，而非 <code>IS NOT NULL
Django/Flask 里怎么封装游标分页逻辑
别在视图里手拼 SQL —— 容易漏索引、错方向、编码失败。封装成可复用的查询构造器更稳。
关键点不是“怎么调用”，而是“怎么保证生成的 SQL 能走索引”。比如 Django 的 filter() 链式调用若混入 __lt 和 __gt，可能被 ORM 拆成多个 WHERE 子句，破坏联合索引使用。
- Django 推荐用
extra()或原生 SQL：例如.extra(where=["(created_at, id) - Flask + SQLAlchemy 可用
text()：例如session.execute(text("WHERE (created_at, id) - 永远校验游标参数类型：
cursor_time必须是datetime，cursor_id必须是int，非法输入直接 400，不进 DB - 返回结果里带上新游标：取最后一条的
(created_at, id)，Base64 编码后塞进响应的next_cursor字段
什么时候该坚持用偏移量，而不是强行上游标
游标不是银弹。有些业务场景硬套游标反而增加复杂度甚至出错。
典型翻车现场：用户按“价格从低到高”排序商品，但价格重复率极高（比如 99% 商品都是 ¥99）。这时用 (price, id) 当游标，一页可能只返回 1 条，体验极差。
- 适合偏移量的场景：排序字段基数高（如时间、UUID）、前端明确禁止跳页、数据实时性要求低（可接受缓存 COUNT）
- 混合策略可行：对“最新动态”用游标，对“按销量排序”用带缓存的偏移量（
COUNT结果缓存 5 分钟） - 千万别把游标当成“高级 OFFSET”来用——它本质是“流式读取”，不支持随机跳页，也不适合做后台导出（导出需要全量）
游标分页真正的坑不在实现，而在边界：时间字段精度（毫秒还是秒）、时区处理（DB 存 UTC，前端传东八区时间）、以及当排序字段被更新时（比如订单状态变更导致 updated_at 改写），游标是否还稳定。这些细节不压测根本看不出来。
