mysql 直接 select sum(amount) from .... 和先 select amount from ... 然后用 Java 求和有什么区别吗？
MeloForsaken · 2020-08-13 15:55:12 +08:00 · 4912 次点击这是一个创建于 1564 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，在内存使用和速度上有什么区别
 |
1
lpts007 2020-08-13 16:04:53 +08:00 via Android
怎么都是前者好吧。这种语句也会成为瓶颈吗？
|
 |
2
harde 2020-08-13 16:15:55 +08:00
1 行没啥区别，1 万行差别就太大了。。。。
|
 |
3
Hurriance 2020-08-13 16:18:14 +08:00
个人见解哈，我是希望 db 压力尽可能小的，所以 sql 能多简单就多简单，把需要的运算尽可能放在应用中解决。模拟一下数据量，预估 sql 的 execution 、fetching 和应用计算所需时间，最终根据你是权重时间还是 db 的吞吐量来选择了。
|
 |
4
OysterQAQ 2020-08-13 16:18:31 +08:00  1
mysql 衡量查询开销三个指标：响应时间、扫描的行数、返回的行数。你这两方式都不太好，非要比 java 求和更差，看场景 精度不高的话维护汇总表就好
|
 |
5
FrailLove 2020-08-13 16:24:01 +08:00
第一个 db 仅需 传输一个 amount 到服务器端
第二个 db 需要传输每一行到服务器端 |
 |
6
cheng6563 2020-08-13 17:37:09 +08:00
数据多的时候 1 快得多，但容易让整个数据库卡死。
|
 |
7
linxb 2020-08-13 17:47:59 +08:00
看数据量吧，以 100 万条数据求和为例，1 需要的时间至少 10 来秒，2 不清楚
|
 |
8
tikazyq 2020-08-13 18:07:24 +08:00 via iPhone
写 java 代码求和… 首先，代码量要多一些吧；其次，数据库执行加和是执行计划优化过的，性能肯定要比程序自己单线程遍历快；然后，从数据库读取所有行占用的网络资源要比一条结果数据多吧；最后，java 是一次性读取吧，如果一亿行数据是不是得吃满内存？总之，作为一个负责的程序员，怎么都不应该首先考虑在程序中进行聚合计算，除非你的数据库无法支持这种聚合操作，例如 redis
|
 |
9
JaguarJack 2020-08-13 20:18:00 +08:00 via iPhone
如果这个字段加索引呢，一和二区别大吗
|
 |
11
changdy 2020-08-13 21:01:01 +08:00
哈 想法不错..思路是不是错了?
如果只是简单的求和 无脑数据库计算, 怎么会想着先求出列,然后在代码上求和? 如果是一些复杂计算 比如地理位置信息, 复杂三角函数转换,这种后端才比着 db 有优势啊. |
|
12
changdy 2020-08-13 21:02:57 +08:00
当然从描述上来说肯定
@OysterQAQ 4l 说的最完善... 3l 老哥是不是压根都没看 sql....还是从一个极端进入了另一个极端? |
 |
13
fiypig 2020-08-13 21:26:02 +08:00 1
我个人想法是 1...,2 的方法有点难以理解
|
 |
14
sagaxu 2020-08-13 21:31:00 +08:00 via Android
10 万个数求和是极快的，把 10 万个数拼到结果集里返回，消耗的 CPU 和内存可能比求和还大。
|
 |
15
Jooooooooo 2020-08-14 00:45:25 +08:00
请节省宝贵的 db 资源
可以分页捞然后程序里面求和 |
 |
16
xupefei 2020-08-14 01:28:41 +08:00 1
楼上有些回复真特么神了。
如果数据量能让 sum 卡死，你猜方案 2 会不会把网络炸掉？ |
 |
17
watzds 2020-08-14 01:46:46 +08:00 via Android
真逗，奇思妙想
|
 |
18
levelworm 2020-08-14 07:31:35 +08:00 via Android
上 DWH push 到数据库端啊，数据库擅长的就留给数据库。
|
 |
19
loading 2020-08-14 07:42:09 +08:00 via Android
我认为 sum 更好，用 java 说能减轻 db 压力是没考虑 selecr 后 db 需要 io 输出，行越多越惨！
当然。这个 sum 可能只是举例，其他语句要另外分析。 |
|
20
JaguarJack 2020-08-14 07:44:46 +08:00 via iPhone
索引啊 又不会回表
|
 |
21
jjplay 2020-08-14 08:24:45 +08:00 3
数据库不计算，后端不计算，全部丢到前端 去计算，嘿嘿
|
 |
22
VeryZero 2020-08-14 09:02:45 +08:00
一个增加数据库 cpu 压力
一个增加服务器 cpu 和 io 压力 没有绝对答案吧,根据情况选咯 |
 |
23
hand515 2020-08-14 09:06:52 +08:00
网络传输的消耗 对比 求和的那点计算量，我觉得还是让数据库 sum 好
|
 |
24
Egfly 2020-08-14 09:36:47 +08:00
如果能让 db 使用 sum 的时候产生瓶颈，那得多少数据？网络传输耗时估计也很久
|
 |
25
angryfish 2020-08-14 09:47:44 +08:00 via iPhone
如果单纯讨论 sum，那肯定是数据库算好。
|
 |
26
chaleaoch 2020-08-14 09:51:36 +08:00
网络传输也是很大的开销. 选 1. 或其他方案.
|
 |
28
xcstream 2020-08-14 10:33:57 +08:00
数据量大于内存时候 第二种会爆
|
 |
29
qile1 2020-08-14 12:29:03 +08:00 via Android
计算 sum，肯定比，先把数据找到，然后拼接好反会个程序 运算量，io 利用率少
|
 |
30
Aresxue 2020-08-14 12:34:38 +08:00
前者计算是放在数据库进程，后者计算是放在应用进程，后者会浪费很多内存，前者会对数据库产生威胁，你要保大还是保小？
|
 |
31
realpg 2020-08-14 12:38:41 +08:00
真正当做一个问题来做，那就要看业务模型和预期数据量。
如果是 1000 条数据以内，那怎么搞都行 如果是 100000 条数据以内，那直接让数据库算了吧 如果是 100000 条数据以上，那就要看数据库服务器的计算能力会不会产生瓶颈，这个请求的请求量等等 如果是一亿以上，或者 100000 条以上的带复杂逻辑的，那么，在别处进行冗余，依赖 insert update 的触发器进行更新，将集中计算分散化分布化 |
 |
32
wqawd520 2020-08-14 15:10:55 +08:00
说句不好听得话，如果 mysql 连一般得 sum 求和都要放到后端来做，我看还是换数据库把，如果你得 sum 求和得 sql 实在不好写，把数据查出来在后端做，没什么问题。select sum(amoun) from xxx 这在 oracle 和 sqlserver 都不算问题。
|
 |
33
greatbody 2020-08-14 21:31:57 +08:00
楼主其实是想问，如何优化 sum()函数的性能。
答案是换服务器 |
 |
34
chihiro2014 2020-08-14 21:59:03 +08:00
@greatbody 有钱能使磨推鬼
|
 |
35
zhangysh1995 2020-08-15 17:17:55 +08:00
第一个，算完返回。
第二个，拿出来数据交给 Java, 放到内存，Java 处理。噔噔蹬。。。 |
 |
36
goodboy95 2020-08-15 19:25:50 +08:00
如果 sum 换成 count 的话，楼主还会纠结吗？（暂时仅考虑 InnoDB 引擎）
如果不纠结的话，那么，sum 比 count 多耗的那点资源可以忽略不计。 |
Select Language