gorm的limit+offset分页在数据量超10万后性能断崖式下跌，根本原因是数据库需扫描并丢弃前n行，而非跳过；应改用游标分页或索引优化，避免count(*)全表统计，慎用可变排序字段。
为什么 GORM 的 Limit + Offset 在 10 万行后会断崖式变慢
因为数据库执行 SELECT * FROM users LIMIT 20 OFFSET 100000 时，不是“跳过前 10 万行”，而是老老实实扫描、排序（若没走对索引）、丢弃——每翻一页，I/O 和 CPU 开销线性上涨。哪怕 id 有索引，B+ 树仍需逐节点跳转，无法直接定位。这不是 GORM 写得不够“Go”，是 MySQL/PostgreSQL 的执行机制硬限制。
常见错误现象：db.Offset(99999).Limit(20).Find(&users) 在压测中触发数据库 CPU 飙升、连接超时；同一页刷新两次，返回记录顺序不一致甚至漏掉某条。
- OFFSET 超过 5000（MySQL）或 10000（PostgreSQL）就可能明显变慢，取决于索引覆盖程度
- 高并发下，同一 OFFSET 查询因 MVCC 版本不同，可能返回不一致结果
- 别幻想 “GORM 自动优化 OFFSET”——它只是拼 SQL 的工具
游标分页怎么写才不重复、不漏数据
游标分页本质是把“第 N 页”换成“从某条记录之后开始取”，绕开物理扫描缺陷，但写错一个细节就翻车。
- 必须用确定性排序：首字段要有索引、非空、高基数，推荐
ORDER BY id ASC或ORDER BY created_at DESC, id DESC - 多字段排序时，索引必须严格匹配顺序，例如
ORDER BY status, created_at DESC, id DESC对应INDEX idx_status_created_id (status, created_at, id) - 首次请求查
db.Order("id ASC").Limit(21).Find(&users)（多查 1 条判断是否有下一页） - 下一页游标必须基于当前页最后一条记录生成，不是第一条；前端传
last_id，后端直接用于WHERE id > ? - 避免字符串拼接游标值，用
base64.RawURLEncoding.DecodeString解码，防止 URL 中+或/被误解析
GORM 的 Count 查询为什么总不准
db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 这种链式调用，Count 会忽略前面的 Limit 和 Offset，但不一定忽略 Where——行为取决于 GORM 版本和 session 复用逻辑，极易出错。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)隔离条件 - 复杂关联（含
Joins或子查询）：手写子查询更可靠，例如db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE p.active = ?) AS t", true).Scan(&total) - 如果 UI 不强制显示“共 XX 条”，就别查总数——省一次全表扫描，QPS 能翻倍
- 缓存总数量只适用于低频变更数据（如后台配置），用户动态数据缓存反而引入一致性风险
分页参数校验和排序字段陷阱
GORM 不做任何参数清洗，前端传啥它就拼啥。page=0、page=-1、pageSize=abc 都会让 GORM panic 或生成非法 SQL。
- 用
strconv.Atoi解析前先判空，非数字直接返回 400 Bad Request - page 小于 1 时强制设为 1，不接受“第 0 页”这种语义
- pageSize 必须限制范围（如 1–100），超限要么截断（
min(p.Size, 100)），要么拒掉 - 没加
Order的分页等于抽签：MySQL/PostgreSQL 不保证无序LIMIT的稳定性，尤其在有并发写入时 - 慎用
Order("created_at DESC")——高并发下毫秒级重复极常见，补上id DESC更稳妥
游标分页不是“性能优化技巧”，而是大数据量下保障正确性和稳定性的基本要求。最容易被忽略的是：游标必须来自当前页最后一条记录，且排序字段必须有覆盖索引；否则看似能跑，实则在高并发或数据写入频繁时，漏数据或重复返回几乎必然发生。
