GORM深度分页（Offset > 10万）必须放弃Limit+Offset，因数据库需真实扫描并丢弃前N行，导致响应时间断崖式上涨，这是SQL执行模型的硬限制，无法通过调优解决。
深度分页（Offset > 10万）在 GORM 中必须放弃 Limit + Offset，否则 MySQL/PostgreSQL 会真实扫描并丢弃前 N 行，响应时间断崖式上涨——这不是调优能解决的问题，是 SQL 执行模型的硬限制。
为什么 Offset 超过 5 万就明显变慢
数据库执行 SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 100000 时，并不会“跳到第 100001 条”，而是：先按 created_at 全局排序（可能触发 Using filesort），再逐行计数、跳过前 10 万条，最后取 20 条。数据量越大，跳过的行越多，I/O 和 CPU 消耗越不可控。
常见错误现象包括：
- 同一接口从第 1 页到第 100 页都很快，翻到第 500 页（
OFFSET 9999）开始超时 -
EXPLAIN显示type: ALL或Extra: Using filesort; Using temporary - 加了索引仍无效——因为 WHERE 条件字段类型不匹配（如 DB 是
INT，Go 传了"123"字符串）
实操建议：
- 用
EXPLAIN SELECT ...验证真实执行计划，别信“我建了索引就一定快” - 复合索引必须覆盖 WHERE + ORDER BY，例如查询是
WHERE status = ? AND user_id = ? ORDER BY created_at DESC，索引就得是(status, user_id, created_at) - 避免在分页查询中混用
Preload("Items")——它会导致 N+1 查询，且无法限制每个订单只取最新 3 个子项
游标分页必须用主键或高选择性时间戳
游标分页不是“换种写法”，而是彻底绕过 OFFSET 的语义：不依赖页码，而依赖上一页最后一条记录的确定性排序值（cursor）。
正确姿势是：
- 首选自增主键：
WHERE id > ? ORDER BY id ASC LIMIT 20，前端传last_id，后端取users[len(users)-1].ID作为下一次 cursor - 次选时间戳 + 主键组合：
WHERE (created_at, id) > (?, ?) ORDER BY created_at DESC, id DESC LIMIT 20，避免毫秒级重复导致漏数据 - 禁用单字段
ORDER BY created_at DESC做游标——高并发下单秒插入多条，created_at相同，数据库内部排序不稳定
注意点：
- 首次请求不能用
WHERE created_at > 0这类模糊条件，必须明确起始点，例如ORDER BY id ASC LIMIT 20获取第一批 - 游标值必须走索引：如果
WHERE id > ?中id是主键，天然命中；但若用WHERE order_no > ?，而order_no没索引，照样全表扫 - GORM 不提供原生游标封装，得手动拼条件：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&orders)
总数查询别和分页共用一个 *gorm.DB 实例
db.Where("status = 'paid'").Limit(20).Offset(100000).Count(&total) 查出来的 total 永远 ≤ 20——因为 GORM v2 的 Count() 会继承链式调用中已有的 Limit 和 Offset，这不是 bug，是设计行为。
正确做法是拆成两个独立查询：
- 先构建干净的查询条件实例：
query := db.Where("status = ?", "paid") - 再分别执行：
query.Count(&total)和query.Order("id DESC").Limit(20).Offset(100000).Find(&orders) - 如果总数查询太慢（比如带复杂 JOIN），考虑降级：缓存总数量（定时任务更新）、或前端只显示“下一页”，不显示总页数
容易被忽略的细节：
- 别用
Find().RowsAffected取总数——它返回的是当前页条数，不是全量 - 别在事务里查总数 + 分页列表——事务隔离级别可能导致两次查询看到不一致的数据快照
- 如果业务允许，游标分页可以完全不查总数，前端用“加载更多”代替页码控件
Preload 关联数据必须分两步做
在深度分页场景下，db.Preload("Items").Offset(...).Limit(...).Find(&orders) 是危险操作：GORM 会先查出 20 个订单，再为这 20 个订单发起一条 SELECT * FROM items WHERE order_id IN (1,2,...,20) ——看似合理，但实际可能加载几千条子项，且无法控制“每个订单只取最新 3 条”。
安全做法是分步加载：
- 第一步：查主表 ID 列表（带游标）：
db.Model(&Order{}).Select("id").Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&orderIDs) - 第二步：用 IN 批量查关联数据：
db.Where("order_id IN ?", orderIDs).Order("created_at DESC").Find(&items) - 第三步：在 Go 层按
order_id分组，每组取前 N 条（用map[uint][][]Item+sort）
关键约束：
- IN 列表长度需控制（如 ≤ 1000），避免 MySQL 报
max_allowed_packet错误 - 关联查询必须显式
Order，否则分组后取“最新”无意义 - 不要试图用
Preload(...).Joins(...)一步到位——深度分页 + JOIN 容易触发笛卡尔积，内存爆掉
最常被绕开的点：游标分页不是“升级功能”，而是深度分页的唯一可行路径；而它的稳定运行，极度依赖排序字段的索引质量、类型严格匹配、以及无歧义的 cursor 值传递。少一个环节，线上就可能卡住。
