必须切游标分页：因limit+offset在高频写入时会导致数据重复、丢失及查询雪崩，根本原因是offset需扫描丢弃前n行且无一致性保证；应改用基于主键或时间戳+id的游标分页，并确保排序字段有联合索引。
高频读写表用 Limit + Offset 分页基本等于给自己埋雷，不是慢，是不可靠——数据会漏、会重复、查询会雪崩。必须切游标分页，且排序字段得有索引支撑。
为什么 Limit+Offset 在高频写入场景下必然出错
OFFSET 不是“跳到第 N 页”，而是让数据库从头扫描、逐行计数、丢弃前 N 行。只要表在分页过程中有新插入或删除（比如用户实时注册、订单状态变更），同一条 db.Offset(1000).Limit(20) 多次执行就可能返回不同结果。
- 常见现象：翻页时某条记录在第 49 页和第 51 页都出现，或者直接消失
- 根本原因：MySQL/PostgreSQL 对无主键约束的 OFFSET 查询不做一致性快照保证
- 并发越强、写入越频繁，出错概率越高——这不是 GORM 的 bug，是 SQL 层语义决定的
- 性能断崖点早于预期：OFFSET 超过 5000 就可能触发全表扫描级开销，尤其当 WHERE 条件未命中索引时
游标分页必须怎么写才安全
核心是放弃页码，改用上一页最后一条记录的排序字段值作为下一页起点。最稳的是主键 id，次选是带 id 补充的 created_at。
- 首次请求：
db.Order("id ASC").Limit(20).Find(&users)，不带Where条件 - 后续请求：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users)，lastID必须来自上一页最后一条的id - 前端必须透传
last_id（不是page），后端不做转换，非法值（如负数、非数字）直接返回400 Bad Request - 如果排序用
created_at DESC，条件得改成WHERE created_at ，否则高并发下时间戳重复会导致漏数据 -
id字段必须有主键或唯一索引，否则WHERE id > ?无法走索引，性能反而更差
Count 总数查询怎么避免拖垮性能
高频写入表的 COUNT(*) 本身就很重，尤其带复杂 JOIN 或 WHERE 时。硬查总数往往得不偿失，优先考虑降级方案。
- 别用
db.Where(...).Count(&total)和分页共用一个链式*gorm.DB实例——它会复用前面的Limit/Offset，导致总数永远 ≤ 每页条数 - 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total)隔离上下文 - 复杂关联（含
Joins或Preload）：手写子查询，例如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) - 更现实的做法：对高频接口，总数缓存 5–10 秒；或前端只显示“已加载 20 条”，不显示总页数（无限滚动场景下其实不需要）
- 千万级表慎用
COUNT(*)，MySQL 8.0+ 可考虑information_schema.TABLES估算，但注意该值非实时
Order BY 排序字段必须满足的硬性条件
没加 Order 的分页在任何场景下都不合法，高频写入表尤其敏感。排序字段组合必须能唯一确定每行物理顺序。
- 绝对禁止：
db.Limit(20).Offset(100).Find(&users)（无Order）——数据库返回顺序完全不可预测 - 推荐组合：
Order("id ASC")（最稳）、Order("created_at DESC, id DESC")（时间+主键兜底） - 禁止单用：
Order("status ASC")或Order("name ASC")——重复值太多，内部排序不稳定 - 时间字段必须带精度控制：MySQL 建议用
DATETIME(3)或BIGINT时间戳，避免毫秒级重复引发游标断裂 - 所有排序字段必须落在联合索引中，例如
INDEX idx_created_id (created_at, id)，否则WHERE + ORDER BY会回表甚至全扫
真正麻烦的不是写法，而是说服团队接受“前端不再传 page 参数”——游标分页需要前后端约定透传 last_id 或 cursor，一旦漏掉这个细节，所有优化都白搭。
