GORM的Offset分页越翻越慢，是因为MySQL/PostgreSQL执行OFFSET时必须真实扫描并丢弃前N行，而非跳过；数据量达千万级时，第5000页耗时超3秒，易引发超时、CPU飙升及结果不一致。
Offset分页在GORM里为什么越翻越慢
因为MySQL/PostgreSQL执行OFFSET 100000时，必须真实扫描并丢弃前10万行——不是跳过，是逐行读、逐行比较、逐行丢弃。数据量到千万级，第5000页可能耗时超3秒，连接池被占满，CPU飙升。
常见错误现象：db.Offset(499999).Limit(20)在压测中触发数据库超时；同一页刷新两次，返回顺序不一致，甚至漏掉某条记录。
- 必须加
Order("id ASC")或Order("created_at DESC, id DESC")，否则无序结果不可重现 -
Offset值不能由前端直接传入，要校验page >= 1且pageSize在1–100之间 - 别在
Count()查询里复用带Limit/Offset的DB实例，它会忽略这些条件，导致总数不准
游标分页怎么写才不翻车
游标分页本质是“基于最后一条已知记录继续往后取”，绕开OFFSET的物理扫描缺陷。但写错一个细节，就可能返回空结果或重复数据。
关键点：last_id必须来自上一页最后一条记录的排序字段值，且该字段要有索引、单调递增（id最稳，created_at在高并发下需加id兜底）。
立即学习“go语言免费学习笔记（深入）”；
- 首次请求：
db.Order("id ASC").Limit(20).Find(&users)，不带Where - 后续请求：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端必须传
last_id（不是页码），后端不做转换，直接拼进Where；若last_id非法（如负数、非数字），应返回400而非静默处理 - 如果排序用
created_at DESC，则条件要改成created_at ，且注意时区和精度（建议用<code>datetime(3)或bigint时间戳）
GORM里Count总数怎么查才准又快
db.Model(&User{}).Count(&total)看着简单，但一加Where条件就容易出错：它不会继承主查询的Joins、Preload或Group逻辑，纯按模型表硬扫。
典型陷阱：你写了db.Joins("JOIN profiles ON users.id = profiles.user_id").Where("profiles.active", true)查用户，却用db.Model(&User{}).Where().Count()算总数——结果漏了JOIN条件，总数虚高。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where().Count(&total)隔离会话，避免污染 - 复杂关联：手写子查询
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)
覆盖索引优化：为什么SELECT * 是性能杀手
当SELECT *遇上深分页，MySQL不仅要扫描大量主键，还要对每条做回表（Key Lookup）——拿着主键去聚簇索引里查完整行。偏移量越大，无效回表越多，随机IO爆炸。
比如SELECT * FROM orders ORDER BY created_at DESC LIMIT 1000000, 20，实际要回表1000020次，而其中1000000次全是浪费。
- 改用覆盖索引：确保
ORDER BY字段+查询字段都在同一索引里，例如CREATE INDEX idx_orders_ctime_id ON orders(created_at DESC, id) - 查询只取必要字段：
SELECT id, user_id, amount, status FROM orders WHERE ... ORDER BY created_at DESC LIMIT 20 - 如果必须返回全字段，先用子查询捞出
id：SELECT * FROM orders WHERE id IN (SELECT id FROM orders ORDER BY created_at DESC LIMIT 1000000, 20)
游标分页和覆盖索引不是二选一，而是常要组合使用：先靠id游标保证稳定性，再靠复合索引把WHERE + ORDER BY + SELECT全塞进索引里。最容易被忽略的是——游标值必须来自上一页最后一条的真实字段值，而不是简单加1或减1。
