mysql 直接 select sum(amount) from .... 和先 select amount from ... 然后用 Java 求和有什么区别吗？
MeloForsaken 2020-08-13 15:55:12 +08:00 5442 次点击这是一个创建于 1972 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，在内存使用和速度上有什么区别
 | 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 快得多，但容易让整个数据库卡死。 |
 | 看数据量吧，以 100 万条数据求和为例，1 需要的时间至少 10 来秒，2 不清楚 |
 | 8 tikazyq 2020-08-13 18:07:24 +08:00 via iPhone 写 java 代码求和… 首先，代码量要多一些吧；其次，数据库执行加和是执行计划优化过的，性能肯定要比程序自己单线程遍历快；然后，从数据库读取所有行占用的网络资源要比一条结果数据多吧；最后，java 是一次性读取吧，如果一亿行数据是不是得吃满内存？总之，作为一个负责的程序员，怎么都不应该首先考虑在程序中进行聚合计算，除非你的数据库无法支持这种聚合操作，例如 redis |
 | 9 akagishigeru 2020-08-13 20:18:00 +08:00 via iPhone 如果这个字段加索引呢，一和二区别大吗 |
 | 10 F281M6Dh8DXpD1g2 2020-08-13 20:19:51 +08:00 1 @Hurriance 你知道第一种 db 要传多少数据么..... |
 | 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 akagishigeru 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 Finest 2020-08-14 09:06:52 +08:00 网络传输的消耗 对比 求和的那点计算量，我觉得还是让数据库 sum 好 |
 | 24 Egfly 2020-08-14 09:36:47 +08:00 如果能让 db 使用 sum 的时候产生瓶颈，那得多少数据？网络传输耗时估计也很久 |
| 25 GBdG6clg2Jy17ua5 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 PRO 真正当做一个问题来做，那就要看业务模型和预期数据量。 如果是 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