@echooo0 #9 我测试了，我的 SQL 符合你描述的需求。

对你的 SQL 有些疑问：

1. `partition by c` 没在你的需求描述中体现出来。
2. 运行后报错：

> Error: ER_MIX_OF_GROUP_FUNC_AND_FIELDS: In aggregated query without GROUP BY, expression #2 of SELECT list contains nonaggregated column 'test.tbl.b'; this is incompatible with sql_mode=only_full_group_by

@bthulu #27 实测 5.7 都支持呀。。

@echooo0 #6 是哪个要求没实现呢？

这样？

```sql
SELECT (SELECT SUM(A) FROM table), B
FROM table
ORDER BY createAt DESC
LIMIT 1
```

@Slurp #10 我经常看到，用 Rust 重写其他语言的项目，性能就提升几十倍，的文章，

现在又看到了类似文章，所以就来问问啦

性能有提升吗？

5 年后，AI 能写《日赚过万的代码，要求一运行就打款到支付宝等》了？

@nguoidiqua #49 不是获取分享文件，要读写 几百 GB

是获取 36W 个文件 [列表] ，就要读写 几百 GB （去构建垃圾数据库去了）

正式内容才下载了 几百 MB 。。



楼主的问题，目前看起来是滥用 Eletron 导致的，

可能是预先分片上传内容，存到 IndexedDB ，形成上传队列，再逐一完成上传（猜的）

@arielcc #50 不对噢。。你是上传。。

上传为啥要预先分这么多片存到 IndexedDB 里？

是类似于《预分配所有分片上传任务，形成队列，再逐个上传》么？

是转嫁开发成本给用户？

还是 Eletron 抽象得太好，以至于开发者对这么高成本的代码逻辑都没感知了？

@arielcc #50 夸克网盘本身是 Electron 应用？

看这路径，应该是分片下载，先存到浏览器的 IndexedDB 里，最后再合并？

至于分了多少片，估计很多很多就是了。可以先保存日志，再分析下。

目前看来，还是因为设计垃圾。。

@nguoidiqua #9 开源的 syncthing ，只是获取别人分享的文件目录，就要读写几百 GB ，咋办？

国外的、开源的、重视隐私的、无网页端的、Linux 版也这样的、虚拟机装也防不了的……

@IDAEngine #43 那这俩的效率也太差了吧，哪有获取个文件列表，就库库读写几百 GB 的。。

看人家 eMule 、BT 就好多了，好像（老版） BT Sync 也没有这么高的读写（新版的我记得很吃资源）

@yanqiyu #10 Emm... 换句话说，申请 1GB 虚拟内存，和 100TB 虚拟内存，操作系统付出的代价，是一样的吗？

@arielcc 楼主追踪看看，读写了哪些文件？

目前我只知道可以用 sandboxie 做到，可参考 25 楼，

当时追踪了更过分的微力同步，只是获取了文件目录，就读写了 几百 GB 的垃圾数据库 index-v0.14.0 。。

@yukinomiu #33 看来电脑用大内存还是很有必要的。省得那些软件公司天天转嫁成本给自己。

发布会不是说可以支持吗？当时好像还有人说，能根据设计图，生成全套前端工程来着？

@yukinomiu #30 如果 25 楼采用你说的，放进虚拟机里运行，限制硬盘容量和 IO 速度，估计只会有以下结果：

1. 下载很慢

天翼云盘就是要分 18W 份下载，每一份就是要先丢到临时目录，最后再合并。

还要写 66W 次数据库。限制速度不会让它跳过这些步骤。


同理，微力同步也一定要预先构建 15 GB 的数据库。

我尝试丢到过树莓派上运行，看是不是 Windows 端的问题。

结果就是更慢，但该写的数据，一个 Byte 都少不了。。


2. 下载失败

我建立了内存盘，设置 sandboxie 重定向对 C: 盘的操作到内存盘，D: 盘的正常放行。

设立过小时，这俩软件都说空间不足。。

@yukinomiu #3 楼主是心疼新硬盘被不合理地乱干，虚拟机防不了这个吧？

也有可能只是软件设计得垃圾。我以前用 天翼云盘 和 微力同步 时碰到过。


1. 天翼云盘，在下载一个 4GB 的文件时，保存目录在 D: 盘，但 C: 盘也有 40 GB / hour （ 12 MB/s ） 的速度写入。

用 sandboxie 跟踪文件操作日志，并分析数据，发现有 170W 次文件操作：

- 4GB 的文件被分了 18W 份进行下载，每一份先下载到 C: 的临时目录
- 反反复复开事务写一个 52 KB 的数据库 66W 次（导致反复创建删除 xxx.db-journal ，估计触发了很多 NTFS 的东西）
- 读写配置文件 47W 次（看不懂。。）
- 写目标文件 1500 次
- 还有个 35W 次的，对程序目录的操作，我看不懂。。

分析命令：

```shell
$ awk -F$'\t' -v OFS=$'\t' '$5 ~ /^File/{arr[$7]++} END{for (k in arr) if (arr[k] > 1) print arr[k], k}' sandboxie.log | sort -rn
666140 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud\transManNew_###########@189.cn.db-journal
470862 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud\setting.xml
353936 \Device\HarddiskVolume3\Program Files (x86)\ecloud
1544 \Device\HarddiskVolume9\??????\????????\????????.part11.rar
23 \Device\HarddiskVolume3\Program Files (x86)\ecloud\Config\ecloud\transfercfg.xml
22 \Device\HarddiskVolume3\Program Files (x86)\ecloud\eCloud.exe
18 \Device\HarddiskVolume3\WINDOWS\System32\drivers\etc\hosts
11 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud\setting.xml.tmp
11 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud
6 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud\LogFileTransfer_###########@189.cn.db-journal
4 \Device\HarddiskVolume3\Users\wuxun\AppData\Roaming\ecloud\userinfo.xml
2 \Device\HarddiskVolume9\??????\????????\????????.part11.rar.ecdl
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_ZNx3dAAodr46ERcahHyp
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_z84dXqNPNdgIWChWt1PM
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_Z2RJUJnPusih593Oxc9F
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_ylQaBzpTKmd9O7nXb447
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_XaAabe9g3PxVgRtbBPff
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_X2XEpRBBSfbNoRlXyCSa
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_VW5XBHbCfAMSHQboxLR0
2 \Device\HarddiskVolume3\Users\wuxun\AppData\Local\Temp\etilqs_uSrTPYjHvBhmRWHVahW7
……
```

当时 sandboxie 跟踪文件日志截图：

https://i.imgur.com/Wk219hM.png



2. 微力同步，在获取 zlibrary_cn 大概 36W 个文件的列表信息时，就要读写几百 GB 了（还没咋开始下载真正的文件内容呢）。

跟踪了下，发现只是在构建它的索引数据库 index-v0.14.0.db 。。（不知这数据库咋设计的，36W 个文件信息，就要存 15GB 。。）

当时正从其他 30 人获取文件列表信息：

https://i.imgur.com/XIVxdh3.png

任务管理器发现，这货库库读写 C: 盘：

https://i.imgur.com/Mq5nUGC.png