OFFSET LIMIT 在大数据量下变慢是因为数据库需扫描并丢弃前N行，I/O和CPU开销随偏移量线性增长；应改用基于排序字段的游标分页，通过索引范围扫描提升性能。
为什么 OFFSET LIMIT 在大数据量下越来越慢
MySQL 或 PostgreSQL 中用 OFFSET 10000 LIMIT 20 查询第 501 页时，数据库仍需扫描前 10000 行再丢弃——行数越多，I/O 和 CPU 开销越明显。这不是 Go 代码的问题，而是 SQL 执行逻辑本身导致的性能坍塌。
- 每翻一页，扫描行数线性增长，5000 页 ≈ 扫描 10 万行（假设每页 20 条）
- 即使有索引，
OFFSET仍要“跳过”索引 B+ 树中的对应节点，无法直接定位 - Go 的
database/sql层不会优化这个行为，它只是忠实地执行你写的 SQL
用游标分页（Cursor-based Pagination）替代 OFFSET
游标分页不依赖物理偏移，而是基于上一页最后一条记录的排序字段值做条件查询，例如用 created_at + id 组合做不等式过滤。它能跳过全表扫描，走索引范围扫描，QPS 可提升 10 倍以上。
适用前提：排序字段必须有高基数、非空、有索引（推荐复合索引 (created_at, id)）。
SELECT * FROM posts WHERE created_at < ? AND (created_at != ? OR id < ?) ORDER BY created_at DESC, id DESC LIMIT 21
- 传入上一页最后一条的
created_at和id作为游标参数 -
LIMIT 21是为了判断是否有下一页（取 21 条，返回前 20 条） - 注意处理边界：当
created_at相同时，必须用id做二级排序和过滤，否则会漏数据
Go 后端如何安全封装游标分页逻辑
不要把游标参数拼进 SQL 字符串，也不要在 handler 里重复写 WHERE 条件。建议封装成可复用的构建器，统一处理空游标、方向、排序字段校验。
立即学习“go语言免费学习笔记（深入）”；
- 游标解码应使用
base64.RawURLEncoding.DecodeString，避免 URL 中的+或/被误解析 - 游标值需严格校验类型和长度，防止注入或 panic；比如
id必须是int64，不能是负数或超长字符串 - 返回响应时，下一页游标应基于当前页**最后一条**记录生成，不是第一条
- 禁止在游标中暴露敏感字段（如用户 email），只允许业务主键或时间戳类字段
什么时候还不得不保留 OFFSET 分页
搜索结果页、后台管理列表、需要跳转任意页码（如输入“第 87 页”）的场景，游标分页无法满足。此时只能靠工程手段缓解，而非根治。
- 加缓存：对稳定且访问频次高的页码（如前 100 页），用
redis缓存page:xxx→json结果 - 限制最大页码：
if page > 2000 { return ErrPageTooFar }，前端禁用跳转框或截断输入 - 改用
WHERE id > ? LIMIT 20模拟游标（仅适用于主键自增且无删除场景） - 预计算总数时用
SELECT COUNT(*) FROM table WHERE ...单独走索引覆盖，别和分页查混在一起
真正难的不是写对一页，而是让第 10000 页和第 1 页响应时间基本一致——这要求你在设计阶段就放弃“页码”思维，转向“连续流”思维。
