GORM 的 Limit + Offset 分页在数据量超 10 万后性能断崖式下跌，根本原因是数据库需扫描并丢弃前 N 行；应改用游标分页或索引优化，避免 Count(*) 全表统计，慎用可变排序字段。
直接说结论：GORM 的 Limit + Offset 分页在数据量超 10 万后，性能会断崖式下跌，不是代码写得不够“Go”，是 SQL 执行机制本身决定了它扛不住。真正要稳，得换思路——要么用游标分页，要么靠索引兜底。
为什么 Offset 越大查询越慢？
MySQL/PostgreSQL 执行 SELECT * FROM users LIMIT 20 OFFSET 100000 时，并不会跳过前 10 万行再读，而是老老实实扫描、排序（如果没走对索引）、丢弃——每翻一页，I/O 和 CPU 开销线性上涨。500 页 ≈ 扫 10 万行；5000 页 ≈ 扫 100 万行。这不是 Go 层能优化的，是数据库引擎的硬限制。
- 即使加了
id索引，OFFSET仍需在 B+ 树里逐节点跳转，无法直接定位 - 高并发下，同一
OFFSET查询可能因 MVCC 版本不同返回不一致结果 -
Count(*)全表统计在大数据量下同样耗时，且多数前端根本不需要“总页数”
游标分页怎么写才不踩坑？
游标分页本质是把“第 N 页”换成“从某条记录之后开始取”。它依赖确定的排序字段和索引，稳定性与性能都远优于 Offset。
- 必须用
ORDER BY，且首排序字段要有高基数、非空、有索引（如created_at或id） - 多字段排序（如
ORDER BY status, created_at DESC, id DESC）时，索引必须严格匹配顺序：INDEX idx_status_created_id (status, created_at, id) - 避免直接拼字符串传游标值，用
base64.RawURLEncoding.DecodeString解码，防止 URL 中+或/被误解析 - 首次请求不带游标，查
db.Order("id ASC").Limit(21).Find(&users)（多查 1 条判断是否有下一页） - 下一页游标必须基于当前页最后一条记录生成，不是第一条
GORM 中 Count 查询为什么总不准？
db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 这种链式调用，Count 会忽略前面的 Limit 和 Offset，但**不一定忽略 Where** —— 实际行为取决于 GORM 版本和 session 复用逻辑，极易出错。
立即学习“go语言免费学习笔记（深入）”；
- 简单场景可用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)隔离条件 - 复杂关联查询（含
Joins或子查询）建议手写SELECT COUNT(*) FROM ( ... ) AS t，用db.Raw(...).Scan(&total)执行 - 如果 UI 不强制显示“共 XX 条”，就别查总数——省一次全表扫描，QPS 能翻倍
- 缓存总数量只适用于低频变更的数据（如后台配置列表），用户动态数据缓存反而引入一致性风险
什么时候还不得不保留 Offset 分页？
搜索结果页、后台管理列表、支持任意页码跳转（比如输入“第 87 页”）的场景，游标分页天然不支持。这时只能工程化缓解，没法根治。
- 加 Redis 缓存前几百页（如
cache.Set("page:users:100", json, 10*time.Minute)），命中直接返回 - 服务端校验
page上限，如if page > 2000 { return ErrPageTooFar }，前端同步禁用跳转框 - 用覆盖索引优化原始查询：确保
SELECT字段都在索引里，避免回表，例如INDEX idx_created_id (created_at, id)配合SELECT id, created_at FROM users ... - 绝对不要在生产环境允许
size > 100，网络传输和内存开销会陡增
最常被忽略的一点：游标分页的“排序字段”不能是业务可变字段（比如 updated_at），否则更新导致排序位移，页面会漏或重。主键 id 最稳妥，时间戳类字段必须搭配二级唯一字段（如 created_at, id）才能安全使用。
