OFFSET越大查询越慢，因数据库需扫描并丢弃前OFFSET行，导致I/O和排序开销剧增；无索引时触发filesort，有索引时B+树仍需遍历大量节点。
为什么 OFFSET 越大，查询越慢
因为数据库必须先扫描并跳过前 OFFSET 行，才能返回后续数据。比如 SELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 100000，MySQL 或 PostgreSQL 实际会读取 100020 行再丢弃前 10 万行——磁盘 I/O 和排序开销陡增。
更糟的是，如果 ORDER BY 字段没有索引，还会触发 filesort；即使有索引，OFFSET 值过大时，B+ 树仍需逐层遍历大量叶子节点。
- 避免在高偏移量场景（如后台导出第 5000 页）直接用
OFFSET - 确保
ORDER BY字段有索引，且和LIMIT/OFFSET查询条件顺序一致 - 测试时用
EXPLAIN观察rows和Extra字段：若出现Using filesort或Using temporary，说明分页性能已亮红灯
用游标分页（Cursor-based Pagination）替代 OFFSET
核心思路是“记住上一页最后一条记录的排序键值”，下一页查询只找比它“更大”的记录，跳过全表扫描。
例如按 created_at DESC, id DESC 排序，第一页查：SELECT * FROM posts ORDER BY created_at DESC, id DESC LIMIT 20
假设最后一条是 created_at = '2024-05-01 10:20:30', id = 8892，第二页就查：SELECT * FROM posts WHERE (created_at, id)
- WHERE 条件中必须用复合比较（PostgreSQL/MySQL 8.0+ 支持），不能拆成两个独立条件，否则可能漏数据或重复
- 游标值需从服务端安全透传，不能由前端拼接，防止 SQL 注入
- 不支持跳转任意页（比如直接跳到第 100 页），但对无限滚动、下拉加载等场景更稳定可靠
LIMIT 与 OFFSET 的语法差异和陷阱
MySQL 和 PostgreSQL 都支持 LIMIT m OFFSET n，但 SQLite 只支持 LIMIT m OFFSET n（不支持逗号写法）；而 MySQL 还允许 LIMIT n, m（即 OFFSET n LIMIT m），容易混淆顺序。
常见错误：
— 写成 LIMIT OFFSET 10 20（语法错）
— 在无 ORDER BY 时用分页，结果集顺序不固定，翻页时数据重复或丢失
— OFFSET 传入负数或非整数，多数数据库直接报错：ERROR: OFFSET must not be negative
- 始终显式写
ORDER BY，哪怕只是按主键排序 - 后端接收分页参数时强制校验
page和size，转成OFFSET = (page - 1) * size，并限制最大OFFSET（如 10 万） - 不要信任前端传来的
OFFSET值，它可能被篡改或溢出
什么时候还不得不硬扛 OFFSET
管理后台需要精确跳转到第 N 页、且 N 不大（比如 ≤ 200），或数据量极小（
可做轻量优化：
— 用覆盖索引减少回表，例如只查 id 和 title，就在索引里包含这两个字段
— 对 OFFSET > 1000 的请求加缓存（如 Redis 存 page:237 → [id1,id2,...]），但注意缓存失效策略
- 不要为“理论上可能翻到很后面”而提前过度设计游标逻辑
- 真实慢查往往不是分页本身，而是没走索引的
WHERE条件拖累了整个查询——先看执行计划，再决定要不要换分页方式
