复杂join下count不准，因count不继承joins/where条件，需用独立会话或手写子查询；游标分页须用确定性唯一列组合（如u.id,p.id）；preload一对多分页易致数据爆炸，应改用子查询或两步查。
复杂 JOIN 查询下 Count 为什么不准
你写了 db.Joins("JOIN profiles ON users.id = profiles.user_id").Where("profiles.active", true).Limit(20).Offset(40).Find(&users)，然后顺手调 db.Count(&total)——结果 total 是错的。GORM 的 Count() 不继承 Joins 和 Where 条件，它只认 Model(&User{}) 对应的表，相当于在裸 users 表上 COUNT，漏了关联逻辑。
常见错误现象：Count() 返回 10 万，但带 JOIN 的分页结果只有 800 条；或者总数忽高忽低，前端页码跳变。
- 必须用独立会话隔离：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Joins("JOIN profiles ...").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) - 如果 JOIN 多于两层或含 GROUP BY，子查询几乎必选——
Count()在这种场景下完全不可信
游标分页怎么套在 JOIN 查询里
JOIN 场景下不能直接用 WHERE id > ?，因为主表 id 可能重复出现在结果中（比如一个用户有多个 profile），导致游标值不唯一、跳过数据。
关键点是：游标字段必须来自最终排序结果的**确定性唯一列组合**，且该组合在索引中已覆盖所有 JOIN 条件。
- 优先用主键 + 关联表唯一字段拼游标，例如
WHERE (u.id, p.id) > (?, ?)，配合ORDER BY u.id ASC, p.id ASC - 确保联合索引存在：
CREATE INDEX idx_users_profiles ON users(u.id) JOIN profiles(p.user_id, p.id)（MySQL 8.0+ 支持函数索引可优化） - 前端必须透传两个值：
last_user_id和last_profile_id，后端不做任何转换，原样塞进WHERE - 别用
created_at单独做游标字段——高并发下时间精度不足，容易漏数据
Preload 一对多时分页为何查出爆炸性数据量
db.Preload("Orders").Limit(20).Find(&users) 看似合理，实际执行是：先查 20 个用户，再为这 20 个用户各自发一条 SELECT * FROM orders WHERE user_id IN (1,2,...,20) —— 如果每个用户平均有 50 个订单，就查出 1000 条订单记录，远超预期。
这不是 GORM Bug，是 N+1 查询的自然结果，且无法通过 Limit 控制单个用户的关联条数。
- 改用
Joins+ 子查询：先用SELECT u.* FROM users u JOIN (SELECT user_id, MAX(id) as order_id FROM orders GROUP BY user_id LIMIT 20) o ON u.id = o.user_id拿主表，再单独查关联数据 - 或放弃 Preload，手动两步查：第一步查用户 ID 列表，第二步用
IN批量查订单并按user_id分组 - 若需“每个用户最新 3 个订单”，必须用窗口函数：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY id DESC) rn FROM orders) t WHERE t.rn
OFFSET 超过 5 万行时还硬扛？别试了
MySQL 执行 OFFSET 50000 LIMIT 20 时，不是跳过 5 万行，而是真实扫描、比较、丢弃前 5 万行——哪怕 id 有索引，也要走 5 万次索引查找+回表。实测响应从 12ms 拉到 1.7s，CPU 直接冲到 95%。
这时候优化重点不在 Go 层，而在 SQL 模型和索引设计。GORM 只是拼 SQL 的工具，它不解决底层扫描逻辑。
- 立刻停用传统分页，切游标分页；如果业务强依赖页码（如后台导出），加缓存层预热热门页，而非直查 DB
- 检查排序字段是否在联合索引最左：比如
ORDER BY created_at DESC, id DESC，索引必须是(created_at, id)，否则无法跳过扫描 - 避免在分页查询中用
SELECT *，用Select("id", "name")减少回表和网络传输
