Preload与Limit/Offset组合仅分页主表，关联数据全量加载，易致内存暴涨；正确方案是用Joins+Select扁平化或子查询分页，并确保COUNT和游标基于主表字段。
关联表分页在 GORM 中根本不会“自动生效”，Preload + Limit/Offset 组合下，分页只作用于主表，关联数据仍会全量加载——这是最常被误以为“已分页”的陷阱。
Preload 分页时，Limit 只限制主表行数，关联表不被裁剪
你写 db.Preload("Orders").Limit(10).Find(&users)，GORM 会执行两步：先查 10 个用户，再发一条 SELECT * FROM orders WHERE user_id IN (1,2,...,10)。如果这 10 个用户共关联 5000 条订单，全部都会加载进内存。
- 现象：接口响应慢、内存暴涨、甚至 OOM，但 SQL 日志里只看到两条查询，容易误判为“没 N+1”
- 原因：GORM 的
Preload是事后 JOIN 模拟，无法把 LIMIT 下推到关联子查询中 - 解决方向不是“调优 Preload”，而是换策略：用
Joins+Select显式控制字段，或改用子查询手动分页
Joins 分页需手写子查询才能正确 COUNT 总数
当你用 db.Joins("LEFT JOIN orders ON orders.user_id = users.id").Select("users.id, users.name, orders.amount").Limit(10).Find(&results)，COUNT(*) 不能直接复用同一 DB 实例——Count() 会忽略 Joins 和 Select，返回错误的主表行数。
- 错误写法：
db.Joins(...).Count(&total)→ total 是 users 表匹配行数，不是“带订单信息的去重用户数” - 正确做法：用子查询包装主逻辑，再 COUNT，例如
db.Raw("SELECT COUNT(*) FROM (SELECT DISTINCT users.id FROM users LEFT JOIN orders ... WHERE ...) AS t").Scan(&total) - 注意
DISTINCT users.id，否则一对多会导致重复计数
关联字段排序时，复合索引必须覆盖 WHERE + ORDER BY + JOIN 条件
比如查“每个用户最新一笔订单”，写成 ORDER BY orders.created_at DESC，但 orders.created_at 单独建索引没用——因为 JOIN 后排序是在临时结果集上做，MySQL 无法利用该索引加速。
- 真正有效的索引是联合覆盖：对
orders表建(user_id, created_at)，确保 JOIN 条件user_id和排序字段created_at同时命中 - 若还需按用户状态过滤（如
WHERE users.status = ?），且想让整个查询走索引，就得在users表上建(status, id)，并确保主查询用users.id排序而非orders.created_at - 用
EXPLAIN验证：看type是否为ref或range，Extra是否含Using temporary; Using filesort
游标分页在关联场景下必须基于主表字段生成游标
不要用 orders.id 或 orders.created_at 做游标值——它们不唯一对应主表记录，一次分页可能漏掉某个用户的所有订单，或重复拉取同个用户。
- 安全游标只能来自主表：比如
users.id，或组合users.created_at, users.id（要求created_at非空且高选择性） - 关联数据仍需靠
IN子句加载，但至少主表分页稳定；若要限制每用户只取 1 条订单，得用窗口函数或子查询，GORM 不支持原生写法，需Raw - 前端传游标时，必须校验类型一致：
users.id是uint64，就别接收字符串"123"，否则 MySQL 隐式转换导致索引失效
关联分页没有银弹，关键不是选 Preload 还是 Joins，而是明确你要的是“10 个用户及其全部订单”，还是“10 条用户-订单关联记录”。前者注定无法靠 LIMIT 控制总量，后者必须放弃 Preload 改用扁平结构体 + 手写 SQL。
