17370845950

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 倍以上。

适用前提：排序字段必须有高基数、非空、有索引（推荐复

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 条件。建议封装成可复用的构建器，统一处理空游标、方向、排序字段校验。

• 游标解码应使用 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 页响应时间基本一致——这要求你在设计阶段就放弃“页码”思维，转向“连续流”思维。