sql深度分页卡顿的根本解法是用游标分页替代offset，即以主键或时间戳等有序字段为游标，通过where条件跳转到下一页起始位置，配合索引实现毫秒级响应。
SQL报表分页卡顿时，问题往往出在深度分页（如 OFFSET 100000 LIMIT 20）上。数据库需扫描并跳过前10万行，即使有索引，I/O和CPU开销也会陡增。根本解法不是优化OFFSET，而是绕过它——用“游标分页”（Cursor-based Pagination）或“条件分页”替代。
用主键/时间戳做游标分页（推荐）
适用于数据有序、且分页字段有唯一性或高区分度的场景（如自增ID、创建时间+ID组合）。核心思路：不依赖OFFSET，而记住上一页最后一条记录的排序字段值，下一页查询直接从该值之后取数据。
- 原写法（慢）：SELECT * FROM orders ORDER BY id DESC LIMIT 20 OFFSET 100000
- 改写后（快）：SELECT * FROM orders WHERE id （假设上一页最后id是123456）
- 关键点：WHERE条件必须能命中索引；ORDER BY字段与WHERE字段要一致或兼容；首次分页可查最小/最大值兜底
复合游标应对非唯一排序字段
当按create_time排序，但存在大量同秒数据时，仅靠时间无法精确定位。此时需补一个唯一字段（如id）构成复合游标。
- 上一页最后一条：create_time = '2024-05-20 10:30:00', id = 98765
- 下一页查询：SELECT * FROM orders WHERE (create_time, id)
- 注意括号内元组比较语法，MySQL 8.0+/PostgreSQL支持，老版本可用OR逻辑模拟
避免OFFSET的其他实用策略
- 前端缓存总条数 + 后端只查当前页：不用COUNT(*)全表统计，改用近似值（如EXPLAIN估算）或异步更新总数
- 限制最大页码：业务上很少真需要翻到第5000页，前端禁用过大页码，后端加校验（如page > 1000则报错）
- 分页改“加载更多”：用滚动加载代替页码跳转，天然契合游标模型，用户感知更顺滑
深度分页不是性能调优题，而是设计选择题。换掉OFFSET，用好索引和游标，报表响应就能从秒级降到毫秒级。
