Count查询总比Find慢，因为其需全表或全索引扫描并回表校验条件，且不继承Limit/Offset、易受软删/JOIN污染；应使用独立DB实例、子查询或游标分页优化。
Count查询为什么总比Find还慢
因为Count(*)在大数据量下仍是全表扫描或全索引扫描，尤其当WHERE条件无法走覆盖索引时，它得回表校验每一行是否满足条件。你看到Find查20条只要5ms，Count却要800ms，不是GORM拖后腿，是数据库在老老实实数——哪怕你只想要个数字。
常见错误现象：db.Where("status = ?", "active").Limit(20).Offset(1000).Count(&total)返回的total永远≤20；更糟的是，这个调用还会让数据库执行一次带LIMIT和OFFSET的COUNT，结果错上加错。
- Count不继承
Limit/Offset，但会意外继承Joins、Preload等链式操作，导致SQL语义错乱 - 没加
ORDER BY的分页配Count，可能因MVCC快照不同，总数和当前页数据对不上 - 用
db.Model(&User{}).Where(...).Count()时，若模型定义了SoftDelete字段（如DeletedAt），GORM默认会自动加WHERE deleted_at IS NULL，而你的主查询可能没走软删逻辑，总数虚高
怎么写Count才又准又快
核心原则：Count必须用独立、干净、条件一致的*gorm.DB实例，不能复用分页查询的DB链。
- 简单场景（无JOIN、无Preload）：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total)——NewDB: true确保隔离上下文，避免污染 - 带JOIN的复杂查询：
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)，子查询里只选1，最小化IO - 如果业务允许（比如前端只显示“下一页”按钮，不要求总页数），直接查
size + 1条，有第size + 1条就设has_next = true，省掉Count查询
哪些Count可以干脆不查
不是所有接口都需要精确总数。查一次COUNT(*)在百万级表上可能比主查询还重，而用户根本不在意“共12345页”。
- 用户端无限滚动列表（App feed、消息流）：游标分页天然不需要总数，
last_id传下去就行 - 后台管理类列表（如订单管理）：若数据变更低频且页码固定在前50页，可缓存总数并设TTL（如10分钟），避免每刷一次都COUNT
- 搜索结果页：Elasticsearch等检索引擎本身不提供精确总数，前端早适应了“约2000+结果”，数据库何必硬刚
容易被忽略的性能雷区
你以为加了索引就万事大吉？这几个点一漏，Count照样慢成狗。
-
WHERE字段没索引，或索引顺序和查询条件不匹配（如索引是(a, b)，你查WHERE b = ?，索引失效） - 用了函数包装条件，比如
WHERE DATE(created_at) = '2026-08-20'，索引直接作废 - MySQL 8.0+开启
innodb_stats_persistent但没定期ANALYZE TABLE，统计信息过期，优化器选错执行计划 - GORM日志开着
logger.Info级别，每查一次Count都打完整SQL+耗时，日志IO压垮磁盘
最稳的做法：先用EXPLAIN看Count的执行计划，确认是否走了索引扫描而非全表；再压测验证QPS拐点——别等上线报警才翻文档。
