count(&total)导致内存暴涨，因gorm复用db实例状态（如preload、joins），使数据库扫描关联结果集而非单表；应显式复现条件、用子查询或弃查总数。
Count(&total) 为什么会让内存暴涨
查总数时用 db.Count(&total) 看似轻量，但 GORM 默认会复用当前 DB 实例的全部状态——包括未清空的 Preload、Joins、甚至已执行过的 Limit。这些残留逻辑不会影响 COUNT 的语义（它只数行数），但会强制数据库加载完整关联数据再统计，导致内存飙升。
典型现象：一个带 Preload("Profile") 的查询链，后面跟 Count()，GORM 会生成含 JOIN 的 COUNT SQL，实际扫描的是 users × profiles 笛卡尔积子集，不是单表行数。
- 内存压力来自数据库返回的中间结果集（即使你只想要一个数字）
- PostgreSQL 可能触发 HashAggregate，把整个关联结果缓存进 work_mem
- MySQL 在无索引 JOIN 下会走 Block Nested-Loop，临时表塞满 tmpdir
db.Model(&User{}).Count() 不等于“安全”
db.Model(&User{}).Count(&total) 表面隔离了模型，但若之前调用过 db.Session() 或设置了全局 gorm.Config，仍可能继承隐式条件（如软删除 scope）。更危险的是：它完全忽略你在主查询中写的 Where("status = ?", "active") —— 总数和列表数据对不上。
- 必须显式复现所有过滤条件：
db.Where("status = ?", "active").Model(&User{}).Count(&total) - 如果用了
Joins("LEFT JOIN profiles...")，Model(&User{})会丢掉 JOIN 条件，总数虚高 - 避免在同一个
*gorm.DB实例上连续调用Find()和Count()，它们共享 prepared statement 缓存，可能污染执行计划
手写子查询是唯一可控的 COUNT 方式
当分页涉及多表关联或复杂条件时，硬编码子查询比依赖 GORM 的链式 Count() 更可靠，也更省内存。子查询让数据库只返回一个整数，不构造任何结构体，也不触发 GORM 的反射解析开销。
例如用户 + 活跃档案的总数：
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)
- 子查询里用
SELECT 1而不是SELECT *，避免字段膨胀 - 别省略别名
AS t，MySQL 8.0+ 会报错 - 如果条件里有
IN子句，确保参数数量可控（> 1000 项时拆成多个子查询或改用临时表）
不查总数才是最大的内存优化
前端分页控件显示“共 237 页”，背后是一次全表 COUNT；但用户真正需要的只是“有没有下一页”。多数场景下，查总数是伪需求。
- 游标分页天然规避总数：查
Limit(21)，如果返回 21 条，说明还有下一页；否则就是末页 - 传统分页可改用估算：对百万级表，
EXPLAIN SELECT COUNT(*) FROM users的rows字段误差通常 - 缓存总数只适用于变更频率 cache.InvalidateByPattern("count:*") 主动失效
最常被忽略的一点：COUNT 查询本身不慢，慢的是它迫使数据库加载并丢弃全部符合条件的行——哪怕你只想要一个数字。绕不开这一步时，子查询是底线；能绕开时，就别查。
