count(*)查询在大数据量下必然成为性能瓶颈，因其需全表或全索引扫描；业务应优先判断是否真需精确总数，而非盲目优化sql。
直接说结论：Count(*) 查询在大数据量下必然成为性能瓶颈，不是写法问题，而是 MySQL/PostgreSQL 执行机制决定的——它得扫全表或全索引。想靠“优化 SQL”硬扛，不如先判断业务是否真需要精确总数。
为什么 db.Count(&total) 总是慢得反常
常见错误现象：db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 返回的 total 永远 ≤ 20；或者查一个带 Joins 的列表时，Count 耗时比主查询还高 3 倍。
-
Count()会复用链式调用中已有的Limit和Offset（GORM v2 默认行为），不是 bug，是设计如此 - 即使加了
WHERE条件，若没显式隔离 session，Count仍可能漏掉Joins或Preload的关联逻辑 - MySQL 对
COUNT(*) FROM users WHERE ...在无覆盖索引时，必须回表或扫描聚簇索引，百万级表轻松耗时 800ms+ - PostgreSQL 的
seq scan在大表上同样不可控，且VACUUM状态会影响估算偏差
db.Session(&gorm.Session{NewDB: true}) 是什么，又为什么不够用
这个写法能解决“复用 Limit/Offset”的问题，但只适用于简单场景——比如单表 + 单 WHERE 条件。一旦涉及关联、子查询或函数字段，它就失效了。
- 它新建的是独立
*gorm.DB实例，但不复制Joins、Scopes或自定义SELECT字段，所以db.Joins("JOIN profiles...").Where(...).Session(...).Count()仍可能漏 JOIN 条件 - 如果主查询用了
GROUP BY或窗口函数，Count根本无法复现语义，强行套用会返回错误结果 - 真正安全的做法是：把主查询的
FROM+WHERE+JOIN部分拎出来，包一层SELECT COUNT(*) FROM ( ... ) AS t - 示例：
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)
不查总数，怎么让前端知道“还有下一页”
多数列表 UI 并不需要“共 123456 条”，只需要“还能加载”。这时候查 size + 1 条，比查总数快得多，也更可靠。
- 首次请求：用
db.Order("id ASC").Limit(21).Find(&users)（比如每页 20 条，多查 1 条） - 若
len(users) == 21，则返回前 20 条 +has_next: true；否则返回全部 +has_next: false - 游标分页同理：查
WHERE id > ? ORDER BY id LIMIT 21，判断是否满额即可 - 这个模式完全绕开
COUNT(*)，QPS 提升明显，尤其在高并发搜索接口中 - 注意：不能省略
ORDER BY，否则多查 1 条无法保证“最后一条”是边界值
最易被忽略的一点：缓存 total 只对低频变更数据有效。用户列表、订单流水这类实时性要求高的场景，缓存总数反而会误导前端——刚删掉 10 条，缓存里还显示 “共 5000 条”。不如彻底放弃总数，专注把游标和排序做稳。
