Spring JPA服务端API用Java stream计数还是多次调用count查询更优？

先说核心结论：除了表数据量长期稳定在千行以内的极端场景，方案1（三次MySQL count查询）的性能和成本效益远高于方案2。

性能对比 #

• 数据库侧开销
  如果你的三个过滤条件匹配了对应索引，MySQL的count操作可以直接走索引统计行数，不需要回表读取实际数据，单次查询延迟基本在毫秒级，三次查询的总开销也极低。就算没有索引，三次count的计算也是在数据库引擎层直接完成，不需要额外的数据传输开销。
  方案2需要先做全表扫描，再把所有行数据序列化后通过网络从AWS RDS传输到你的Spring服务节点，单这一步的开销就远高于三次count查询：万行级别的表就会产生数MB的传输量，十万行级别传输延迟就能升到几十毫秒。
• 应用侧开销
  方案1只需要处理三个整数返回值，CPU、内存开销可以忽略。
  方案2需要把全表数据全部加载到JVM堆内存，再做三次Stream遍历计算，数据量稍大就会频繁触发Young GC，甚至出现OOM，同时API响应时长会大幅上涨，服务吞吐量直接下降。
• 并发场景表现
  方案1的数据库连接占用时间极短，高并发下对连接池的压力很小。
  方案2的查询会长期占用数据库连接直到全量数据传输完成，很容易把连接池占满，导致后续请求直接阻塞。

成本效益对比 #

• 云资源成本
  方案1对RDS的CPU、IOPS消耗极低，应用侧也不会产生额外资源消耗，没有额外成本。
  方案2会大幅推高RDS的读取IOPS和CPU占用，同时应用侧的CPU、内存消耗也会明显上涨，你需要更高配置的RDS和计算节点才能支撑同等流量，长期运行成本要高很多。
• 维护成本
  方案1后续如果数据量上涨，只需要给对应过滤条件加索引就能维持性能，优化成本极低。
  方案2只要表数据量破万就会出现明显的性能下降，几乎没有可优化的空间，最终还是要改回方案1，维护成本极高。

额外优化建议 #

方案1还可以进一步优化成单次查询返回三个计数结果，避免三次查询的往返开销，写法参考：

SELECT 
  COUNT(IF(condition1, 1, NULL)) AS count1,
  COUNT(IF(condition2, 1, NULL)) AS count2,
  COUNT(IF(condition3, 1, NULL)) AS count3
FROM your_table;

如果过滤条件有索引，这个查询的性能比三次单独count还要好。

内容的提问来源于stack exchange，提问作者Niloy Rashid