GORM分页内存暴涨主因是默认加载longtext等大字段，应显式Select指定摘要字段；Count(*)慢因复用大字段子查询，需用Session隔离或手写SQL；游标分页可规避扫描大字段，依赖轻量排序字段索引。
大字段导致分页内存暴涨怎么破
查 50 万条带 longtext 字段的记录，db.Find(&users) 一执行，Go 进程内存直接飙到 2GB——不是数据库慢，是 GORM 把所有大字段全加载进内存再反射赋值。你不需要每页都读正文，但默认行为就是全取。
核心解法就一条：Select() 显式指定字段，把大字段从查询里踢出去。
- 分页接口只返回列表摘要（如
id,title,created_at,summary），正文留到详情页再查 - 别用
Find(&users)，改用Select("id, title, created_at, summary").Find(&users) - 如果结构体里有
Content string `gorm:"type:longtext"`字段，但当前查询不需它，务必Select()过滤掉，否则 GORM 仍会尝试填充（即使 DB 没返回） - 配合
Preload时更要注意：关联表的大字段也得单独Select，否则预加载照样拉全量
分页时 COUNT(*) 为什么比主查询还慢
你在分页接口里写了 db.Where(...).Count(&total)，发现这个 COUNT 比主查询还耗时——大概率是因为大字段参与了子查询。GORM 默认的 Count 会复用主查询的 Select 字段，哪怕你只想要行数，它也可能生成 SELECT COUNT(*) FROM (SELECT id, title, content FROM ...) 这种带 content 的子查询，触发全字段扫描。
正确做法是彻底隔离 COUNT 查询，且不带任何大字段：
- 用
Session(&gorm.Session{NewDB: true})创建新 DB 实例，避免条件污染：db.Session(&gorm.Session{NewDB: true}).Model(&Post{}).Where(...).Count(&total) - 复杂场景（如带
Joins或Preload）直接手写子查询：db.Raw("SELECT COUNT(*) FROM posts WHERE status = ?", "published").Scan(&total) - 如果业务允许，干脆去掉总数，只查
size + 1条，靠最后一项是否存在判断has_next
游标分页为什么能绕开大字段性能陷阱
传统 OFFSET 分页在大字段场景下雪上加霜：MySQL 要扫描并丢弃前 N 行，每行都含 longtext，IO 和内存压力双高。游标分页不依赖偏移量，而是用排序字段值做边界，天然规避全扫。
关键点在于排序字段必须轻量、有索引、且不包含大字段：
- 强制用
id ASC或created_at DESC, id DESC排序，确保索引覆盖，不回表查大字段 - 游标参数只传上一页最后一条的
id和created_at，SQL 变成：WHERE created_at - 注意：不能用
content LIKE "%xxx%"这类条件做游标，会导致索引失效，又退回全扫 - 如果必须按大字段内容分页（极少见），只能建函数索引或改用 Elasticsearch
大字段索引和查询条件怎么设才不拖垮分页
有人给 longtext 字段加 index 标签，结果迁移失败或插入变慢——longtext 不支持全文索引以外的常规索引，GORM 的 gorm:"index" 在这里无效。
真正有效的做法是分层处理：
- 搜索需求走
LIKE前缀匹配（如title LIKE "xxx%"），并在title上建普通索引 - 模糊正文搜索必须用全文索引：MySQL 需
FULLTEXT(content)，查询用MATCH(content) AGAINST(? IN NATURAL LANGUAGE MODE)，GORM 用Raw()执行 - 不要在分页主查询里写
WHERE content LIKE "%xxx%"，这种无索引扫描会让分页彻底不可用 - 如果业务真要基于正文分页，先用全文索引查出
id列表，再用WHERE id IN (?)关联主表分页，拆成两步
