mysql 直接 select sum(amount) from .... 和先 select amount from ... 然后用 Java 求和有什么区别吗？

[MeloForsaken]

如题，在内存使用和速度上有什么区别

[lpts007]

怎么都是前者好吧。这种语句也会成为瓶颈吗？

[harde]

1 行没啥区别，1 万行差别就太大了。。。。

[Hurriance]

个人见解哈，我是希望 db 压力尽可能小的，所以 sql 能多简单就多简单，把需要的运算尽可能放在应用中解决。模拟一下数据量，预估 sql 的 execution 、fetching 和应用计算所需时间，最终根据你是权重时间还是 db 的吞吐量来选择了。

[OysterQAQ]

mysql 衡量查询开销三个指标：响应时间、扫描的行数、返回的行数。你这两方式都不太好，非要比 java 求和更差，看场景 精度不高的话维护汇总表就好

[FrailLove]

第一个 db 仅需 传输一个 amount 到服务器端
第二个 db 需要传输每一行到服务器端

[cheng6563]

数据多的时候 1 快得多，但容易让整个数据库卡死。

[linxb]

看数据量吧，以 100 万条数据求和为例，1 需要的时间至少 10 来秒，2 不清楚

[tikazyq]

写 java 代码求和… 首先，代码量要多一些吧；其次，数据库执行加和是执行计划优化过的，性能肯定要比程序自己单线程遍历快；然后，从数据库读取所有行占用的网络资源要比一条结果数据多吧；最后，java 是一次性读取吧，如果一亿行数据是不是得吃满内存？总之，作为一个负责的程序员，怎么都不应该首先考虑在程序中进行聚合计算，除非你的数据库无法支持这种聚合操作，例如 redis

[JaguarJack]

如果这个字段加索引呢，一和二区别大吗

[liprais]

@Hurriance 你知道第一种 db 要传多少数据么.....

[changdy]

哈 想法不错..思路是不是错了?
如果只是简单的求和 无脑数据库计算, 怎么会想着先求出列,然后在代码上求和?
如果是一些复杂计算 比如地理位置信息, 复杂三角函数转换,这种后端才比着 db 有优势啊.

[changdy]

当然从描述上来说肯定
@OysterQAQ 4l 说的最完善... 3l 老哥是不是压根都没看 sql....还是从一个极端进入了另一个极端?

[fiypig]

我个人想法是 1...,2 的方法有点难以理解

[sagaxu]

10 万个数求和是极快的，把 10 万个数拼到结果集里返回，消耗的 CPU 和内存可能比求和还大。

[Jooooooooo]

请节省宝贵的 db 资源

可以分页捞然后程序里面求和

[xupefei]

楼上有些回复真特么神了。
如果数据量能让 sum 卡死，你猜方案 2 会不会把网络炸掉？

[watzds]

真逗，奇思妙想

[levelworm]

上 DWH push 到数据库端啊，数据库擅长的就留给数据库。

[loading]

我认为 sum 更好，用 java 说能减轻 db 压力是没考虑 selecr 后 db 需要 io 输出，行越多越惨！

当然。这个 sum 可能只是举例，其他语句要另外分析。

[JaguarJack]

索引啊 又不会回表