列表统计查询最好和明细拆开

刚接触 Sequelize 时，很多人喜欢用一条查询同时把总数和明细都拿回来，觉得这样“更省请求”。但在复杂列表里，我越来越倾向把 count 和 rows 拆开，因为它们的目标根本不是一回事。

明细查询需要排序、字段裁剪和关联信息；统计查询只需要知道“符合条件的总共有多少”。如果把这两件事绑在一起，SQL 很容易因为 join、group 或 distinct 出现性能抖动，甚至统计结果还会不准。

比较稳的策略通常是：

• 先构造一份纯筛选条件。
• count 查询只复用筛选，不带多余排序和展示字段。
• rows 查询再补上分页、排序和必要关联。

这样虽然看起来多跑了一次查询，但整体往往更可控。列表接口真正重要的是稳定可预测，而不是理论上的“合并一步”。

为什么这类问题总会在线上阶段突然变贵

围绕「列表统计查询最好和明细拆开」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。