SELECT COUNT() 不能直接套在带 LIMIT 的查询里，因为 LIMIT 只限制返回行数，COUNT() 统计的是结果集行数而非总匹配数；分页需先用独立 COUNT(*) 查询获取符合条件的总条数，再执行带 LIMIT/OFFSET 的数据查询，且两者 WHERE 条件与参数顺序必须严格一致。
为什么 SELECT COUNT(*) 不能直接套在带 LIMIT 的查询里
因为加了 LIMIT 后，COUNT(*) 统计的只是当前页的数据条数，不是全表或条件匹配的总条数。分页时用户需要知道“一共有多少页”，这必须基于完整符合条件的数据量，和当前页偏移、限制无关。
常见错误是写成这样（错）：
SELECT COUNT(*) FROM users WHERE status = 'active' LIMIT 20 OFFSET 40结果永远是 ≤20，毫无意义。
正确做法是：先单独查一次总数，再查一页数据。两个查询独立执行，共享相同 WHERE 条件。
用 database/sql 手动查两次最可控
Go 标准库不内置分页抽象，手动控制 SQL 和参数最稳妥，避免 ORM 隐藏行为导致总数/列表不一致。
- 先执行
SELECT COUNT(*)查询，用QueryRow().Scan()获取总数 - 再执行带
LIMIT和OFFSET的主查询，用Query()扫描结果 - 两个查询的
WHERE条件字符串和参数必须完全一致，否则总数和列表对不上 - 如果用了
ORDER BY，必须保证排序逻辑稳定（比如加上id作二级排序），否则同页数据可能因排序抖动而重复或遗漏
示例片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
countSQL := "SELECT COUNT(*) FROM posts WHERE author_id = ? AND published = true"
var total int
err := db.QueryRow(countSQL, authorID).Scan(&total)
if err != nil { /* handle */ }
<p>listSQL := "SELECT id, title, created_at FROM posts WHERE author_id = ? AND published = true ORDER BY created_at DESC, id DESC LIMIT ? OFFSET ?"
rows, err := db.Query(listSQL, authorID, limit, offset)
// ... scan rows用 pgx 或 sqlx 简化扫描但不省略逻辑
第三方库能减少样板代码，但不会自动帮你做“查总数+查列表”这个核心流程。比如 sqlx.Select() 只负责填充结构体，不提供总数获取能力。
-
sqlx.Get()或sqlx.Select()可替代原生Scan()，但总数仍需单独sqlx.QueryRowx() -
pgx的QueryRow().Scan()行为和标准库一致，但支持更丰富的类型映射（如pgtype.JSONB） - 别依赖
Rows.Err()判断总数查询失败——它只反映扫描阶段错误；QueryRow().Scan()失败会直接返回 error
注意：某些 pgx 版本（如 v5）默认开启 prefer_simple_protocol，对 COUNT(*) 这类单值查询无影响，但若后续扩展为多列聚合，需确认协议兼容性。
总数缓存或估算适用于高并发读场景
当表行数极大（千万级以上）、且总数不需要绝对精确时，可考虑绕过实时 COUNT(*)。
- PostgreSQL 可查
pg_class.reltuples（快，但非实时，适合后台任务参考） - MySQL 用
SHOW TABLE STATUS查TABLE_ROWS（MyISAM 准确，InnoDB 是估算） - 业务层加 Redis 缓存总数，配合写操作更新（如新增/删除后
INCRBY），但要注意分布式锁或原子操作防并发偏差
这类方案本质是用一致性换性能，上线前必须明确告知前端：“页码栏显示的是近似总页数”。真要强一致，还是得走两查。
最容易被忽略的是条件参数绑定顺序——WHERE a = ? AND b = ? 和 WHERE b = ? AND a = ? 在逻辑上等价，但传参顺序一旦错位，总数和列表就会基于不同条件计算，问题极难复现。
