我觉得是排序导致的，把 order by 去了可能时间上会差不多。最直接办法还是看看 explain, 盲猜 in 过滤一堆数据，但是因为你最后是 datetime 排序，所以这个排序做了一个临时表去排。
理论上数据库应该是能利用索性查这个的，但是你用的数据库可能就傻傻的都查出来再排了。

技术上，wifi 的名字是 essid, 还有个类似于 mac 的 bssid.
要是软件安全性好，完全可以识别出这种攻击，但是防御效果也有限。

大部分程序员，可能对网络和文件系统接口都不熟。
现代操作系统提供的网络基本上都不会出现传输错误，现代操作系统也都会提供 seek+随机写的功能。
对于 preallocate 会有各种实现方式，不过提供的结果基本一致，也就是实现了随机写。另外，即使不依赖 seek ，也可以有 mmap 这样的方式实现随机写。
再说从网络下载到磁盘，大部分操作系统也会提供 zero-copy 或者类似 pipe 的功能，即使没有，IO 操作时基本上也是使用一个固定 buffer ，比如 64k ，不会把全部内容放到内存再操作。
再说一下状态恢复，类似数据库一样，分片的下载状态一般是单独存放，比如 aria 、flashget 或者迅雷，只有分片下载完成后再去更新状态，这样即使程序崩溃，也可以下次启动从恢复点续传。
最后补充一个极端的例子，BT 下载每次传输单元是 16KB ，难不成要创建一堆 16KB 的文件，然后完成之后再合并？从文件系统的效率角度来说，从 socket 读并且单独写入一个大文件，这里可以只需要频繁调用 read(socket) + write(fd)。 但是如果是一堆小文件，你需要频繁创建和关闭文件，这两个操作在大部分操作系统，尤其是 HDD 上的文件系统，开销会非常大，你的顺序写操作会变成随机写，同时如果你的操作系统安装了杀毒软件，杀软也会在文件关闭时进行扫描，结果就是更慢了。

一般程序员在软件设计和实现的时候，都会倾向于使用资源需求最小并且吞吐量高的方案。所以当小文件没有明显优势，而且特殊场景下资源开销和性能都有明显损耗的情况下，选择大文件是一个比较自然的方案。

类似的需求还有比如数据库，就像如果网络客户端发送了一些 INSERT ，你是把他们写入小文件然后再合并呢，还是直接放到大文件中。这里的就会有和网络下载类似的权衡，当然也有不一样的地方。

@kenvix 你以为这样的程序员是段子？他其实是认真的，就感觉没啥讨论下去的意义。

我大学时有个类似的习惯，就是读维基百科，当时有维基百科离线版，做成类似词典那种。
我就一直 BFS 看，每次看到崭新的领域就觉得爽。
就单纯的爽

一般都是写到一个大文件吧，下载到单独文件，相当于 IO 两次，除了某些场景下，现在的 OS 对于这个没有特殊差别。
但是对于真的大文件，比如 10GB 以上的，你这种写两遍的操作会占用两倍的磁盘空间，而且对于 HDD ，一边读一边写会巨慢。
所以，这么做，单纯的是菜（不会 seek ）。

面向网盘+图片的 CMS 系统？

@Misakas 一般不会不是 8 的倍数，程序员不会自己没事找事。

collected?

@changdy 小白 allinone 吧。

@msg7086 感谢 我的网络是 T-Mobile

我是 google photos+黑群晖
因为目前 selfhosted 的照片备份（ ios+安卓）只有群晖的还算能用。

你这外观像极了我之前用过的一款手机，不过再加一个游戏键盘。

设置下这个参数看看？
wiredTiger:
engineConfig:
cacheSizeGB:

是的，对于优化不好的场景，会有较大的性能损失。
能实现。
你并不需要真的机器，你可以用 vm 起 pve ，然后 vm 里搭建 ceph 集群。

@2wex 但是感觉这些机器可能就值这些钱，连个 90w 快充都没有，红米都有 120w 快充

@night98 真我手机还有区域网络锁？

@Jirajine 我觉得这是 snap 这种类似于绿色软件的打包办法，比起 deb 的方案对于某些用户友好很多，就不容易装新软件出现一堆库冲突。
而且像复杂的软件，比如 lxd 和浏览器, 也能包进来，用户体验类似 apk 这种 allinone 的软件包，比起装个 chrome 还要一万个依赖，体验好一些。

同求,  就大概 vb6 那种感觉的