直接对含大JSON字段的表用OFFSET分页会严重拖慢性能，因为数据库仍需加载并丢弃前N行完整记录（含JSON解析、内存分配等开销），即使只SELECT id；根本原因是SQL OFFSET模型的固有缺陷，与GORM无关。
为什么不能直接对含大JSON字段的表用 OFFSET 分页
因为 JSON 字段本身不影响分页逻辑，但大 JSON 会显著拖慢 OFFSET 扫描——MySQL/PostgreSQL 在执行 OFFSET 100000 时，仍需加载并丢弃前 10 万行的完整记录（含 JSON 解析、内存分配、序列化开销），哪怕你只 SELECT id。这不是 GORM 的锅，是 SQL 分页模型的固有缺陷。
- JSON 字段越长、嵌套越深，单行体积越大，OFFSET 越卡顿
- 即使加了
SELECT id, name，只要表结构含 JSON 列且未被覆盖索引排除，InnoDB 仍可能回表读取整行 - GORM 的
Limit/Offset不会自动裁剪 JSON 字段；它只是透传给数据库
如何让带 JSON 字段的分页不崩
核心是「不让数据库扫描无用 JSON」。优先级从高到低：
- 建覆盖索引：比如常用
ORDER BY created_at DESC, id DESC分页，就建INDEX idx_created_id (created_at, id)—— 确保查询能走索引，避免回表读 JSON 列 - 分页时显式指定字段：用
db.Select("id, name, created_at").Order("created_at DESC, id DESC").Limit(n).Offset(m).Find(&users)，别用Find(&[]User{})全字段查 - 如果业务允许，把 JSON 拆到独立表（如
user_profiles），主表只留轻量字段用于分页，查详情时再 JOIN 或按需预加载 - 对 JSON 内容本身做分页？不行。GORM 不支持对 JSON 数组字段做子分页（比如 “取 attrs.tags 的第 2–5 个元素”），得靠数据库函数（MySQL
JSON_EXTRACT）或应用层处理
Count 查询 JSON 表时容易错在哪
带 JSON 字段的 Count 本身不慢，但容易写错逻辑：
-
db.Model(&User{}).Where("attrs->'$.status' = ?", "active").Count(&total)是 OK 的，JSON 路径表达式可下推到 WHERE - 但
db.Where(...).Limit(20).Offset(40).Count(&total)会返回 20（因为复用了 LIMIT），必须隔离会话：db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 若 JSON 字段参与 JOIN（如
Preload("Profile")），Count 可能因笛卡尔积虚高，此时应手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u WHERE u.attrs->'$.type' = ?) AS t", "admin").Scan(&total)
大数据量 + JSON 字段，该换游标分页吗
该。尤其当单页数据 > 50 条、总记录 > 50 万、JSON 平均 > 2KB 时，OFFSET 分页响应已不可控。游标分页不是“更高级”，而是绕过 OFFSET 的物理限制：
- 前端传上一页最后一条的
created_at和id（二者组合唯一） - 后端查：
db.Where("created_at - 关键点：WHERE 条件必须匹配 ORDER 字段，且索引要包含全部排序字段（
(created_at, id)） - JSON 字段完全不参与游标逻辑——它只在最终 SELECT 时加载，不影响分页性能
游标分页无法跳转任意页，但对滚动加载、信息流场景更稳；而 OFFSET 的“跳页”能力，在 JSON 大表里往往只是理论可行。
