select count(*)不能直接套在分页查询中，因聚合与非聚合字段混用需group by，违背分页语义；常规做法是两条独立sql：先查总数再查当前页数据，条件与排序必须严格一致。
SELECT COUNT(*) 为什么不能直接套在分页查询里？
因为 COUNT(*) 和带 LIMIT/OFFSET 的查询逻辑不同：前者统计全表或条件匹配的全部行数，后者只返回某一页的数据。把 COUNT(*) 套进同一个 SELECT 里（比如写成 SELECT *, COUNT(*) FROM ... LIMIT 10 OFFSET 20）会报错或返回错误结果——聚合函数和非聚合字段混用时，数据库要求 GROUP BY，而你并不想分组。
最常用且兼容性好的方案：两条独立 SQL
先查总数，再查当前页数据。这是绝大多数业务场景的真实做法，简单、可控、各数据库都支持。
-
SELECT COUNT(*) FROM users WHERE status = 'active';→ 拿到总条数，用于计算总页数 -
SELECT id, name, email FROM users WHERE status = 'active' ORDER BY id DESC LIMIT 20 OFFSET 40;→ 查第 3 页（每页 20 条） - 注意两个查询的
WHERE条件和ORDER BY必须完全一致，否则总数和分页结果对不上 - 如果数据量极大（千万级），
COUNT(*)可能变慢；此时可考虑加覆盖索引，或用近似值（如 PostgreSQL 的pg_class.reltuples）但需权衡精度
MySQL 8.0+ / PostgreSQL / SQL Server 支持的单语句方案
用窗口函数 COUNT(*) OVER() 可以在返回分页数据的同时附带总数，但要注意性能和语义限制。
- PostgreSQL 示例：
SELECT id, name, COUNT(*) OVER() AS total FROM users WHERE status = 'active' ORDER BY id DESC LIMIT 20 OFFSET 40; - MySQL 8.0+ 同样支持，但
OVER()不带PARTITION BY时会扫描全部匹配行，即使只取 20 条，代价仍接近全表扫描 - SQL Server 也支持，但
OFFSET FETCH和OVER()组合时，优化器不一定能跳过多余行，实测比两条语句更慢的情况很常见 - 不推荐在高并发分页接口中无条件使用该方案，尤其当
WHERE条件无法走高效索引时
ORM 框架里怎么避免手写两次 COUNT？
像 Django ORM、SQLAlchemy、MyBatis 这类框架通常封装了分页逻辑，但底层仍是发两次查询——关键在于别被“一行代码分页”的表象误导。
- Django 的
paginator = Paginator(queryset, 20)内部会执行COUNT+LIMIT/OFFSET两步 - MyBatis-Plus 的
PageHelper.startPage(1, 10)同样依赖拦截器自动补COUNT查询 - 警惕某些“智能分页插件”声称“只查一次”，实际可能用子查询或临时表，反而增加锁竞争或内存压力
- 如果用的是原生 JDBC 或轻量 ORM（如 JDBI），务必自己控制这两条 SQL 的条件一致性，别让
COUNT查 A 条件，分页查 B 条件
真正麻烦的不是怎么写 SQL，而是确保总数和分页数据基于同一快照——如果查询期间有大量增删，两次查询之间数据变动，总数和当前页就可能不一致。这种情况下，要么接受最终一致性，要么加事务隔离（但会影响并发性能），没有银弹。
