直接在join后用limit会丢失总行数，因为limit在join结果生成后截断，而count()若同查需两次扫描且结果可能不一致；应拆分统计与取数、保持where一致，或用count() over()窗口函数单次获取总数与分页数据。
为什么直接在JOIN后用LIMIT会丢失总行数
因为 LIMIT 是在 JOIN 结果集生成后才截断的，而 COUNT(*) 如果也加在同一个查询里（比如用子查询套一层），数据库优化器往往无法复用执行计划，导致两次扫描——一次算总数、一次取数据，性能差且结果可能不一致（尤其有并发写入时）。
用子查询先算总数，再用JOIN分页取数据
核心思路是把「统计」和「取数」拆开，但保证两者基于同一逻辑快照。常见做法是：用一个不含 LIMIT 的子查询计算符合条件的主表记录数，再用另一个带 JOIN 和 LIMIT/OFFSET 的查询取分页数据。两者都基于相同的 WHERE 条件。
示例（MySQL）：
SELECT COUNT(*) AS total FROM orders o WHERE o.status = 'shipped'; SELECT o.order_id, u.username, o.amount FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'shipped' ORDER BY o.created_at DESC LIMIT 20 OFFSET 40;
注意：WHERE 条件必须完全一致，否则总数和分页数据对不上；ORDER BY 字段需有索引，否则 OFFSET 越大越慢。
用窗口函数一步拿到总数 + 分页数据（推荐但注意兼容性）
PostgreSQL、SQL Server、MySQL 8.0+ 支持 COUNT(*) OVER()，可在单次查询中同时返回每行数据和总行数，避免二次扫描，且天然一致性高。
示例（MySQL 8.0+）：
SELECT order_id, username, amount, COUNT(*) OVER() AS total FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'shipped' ORDER BY o.created_at DESC LIMIT 20 OFFSET 40;
要点：
-
COUNT(*) OVER()不影响分组，它对整个结果集计数 - 如果
WHERE条件过滤后结果很大，窗口函数仍会计算全部匹配行，内存占用略高 - SQLite 和旧版 MySQL 不支持，得降级用前一种方式
用 EXISTS 替代 JOIN 避免笛卡尔积导致总数膨胀
当主表和关联表是一对多关系时，直接 JOIN 再 COUNT(*) 会把主表行重复计数（例如 1 个订单有 3 个商品，就会计成 3 行），造成总数虚高。此时总数应统计主表满足条件的记录数，而非 JOIN 后的行数。
正确做法：
- 总数用主表独立查询：
SELECT COUNT(*) FROM orders WHERE status = 'shipped' - 分页数据改用
EXISTS或IN关联用户信息（避免重复）：
SELECT o.order_id, (SELECT u.username FROM users u WHERE u.id = o.user_id) AS username, o.amount FROM orders o WHERE o.status = 'shipped' AND EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id) ORDER BY o.created_at DESC LIMIT 20 OFFSET 40;
这种写法确保总数是“订单数”，不是“订单×用户组合数”，语义更准确。
分页 + 总数最易被忽略的其实是「一致性边界」：总数和分页数据是否基于同一时刻的数据快照。高并发场景下，哪怕只差几毫秒，也可能出现总数是 1000，但第 50 页查不到数据的情况。用事务隔离级别（如REPEATABLE READ）或快照时间戳能缓解，但这已超出 SQL 语法本身。
