子查询直接丢 JOIN 不行吗？还是条件更复杂？

SELECT u.id,
u.name,
GROUP_CONCAT(i.email) AS email,
GROUP_CONCAT(i.phone) AS phone
FROM user u
LEFT JOIN (SELECT * FROM contact where conditions) i ON u.id = i.ref_id
GROUP BY u.id;

@yxd19 大部分是软件决定的，其中高可用（ HA ）、容灾冗余、备份等等都是需要硬件资源开销的，例如要做备份你得有额外的存储空间，要做高可用就得做多个 NAS 随时待命这样。

兄弟，大小周别整，没意思，直接新公司
单休不是简单的单休，按一周来看，双休是做 2.5 天休 1 ，单休是做 6 休 1 。

你信得过我就 Hyper Backup 整机加密备份到我白群，我有公网 IP ，每月请我喝杯咖啡就行^ ^

我自己的 321 方案是，A 盘存数据，B 盘存备份，都是 Basic ，A 盘所有备份全部到 B 盘，B 盘走 webdav+rsync 备份到公司白裙。

同蹲

这不是推广么，又发程序员节点了

是的，你理解的没错。
如果简单的存储需求即使如此。
但存储一旦开始需要信安、容灾、高可用、321 之类，就要自己折腾协议、授权认证、备份、计划任务、磁盘清理、（非）结构化检索、文件去重、压缩、加密存储。市面上的产品优势就体现了。
除此之外，容器化、虚拟机之类的本身不是 NAS 职责范围，只是 All in one 方案。

@SomeBodsy 我也是，巧了

短链接如果没有生命周期或者生命周期足够长，那久而久之，就失去了短链接的意义，最终会变成长链接。

我认为短链接分享的初衷是在于够短，短时间内方便快速传播。

啊这，刚搭了个玩，SD-WAN 的解决方案吧，也就配个网在本地做，其它的改防火墙端口啥的都得上它的云管理平台。

时间机器做个备份，删光，检查完还原

@laaaaaa #7 我的意思是三拼.com 域名也已经饱和了，很难很难注册到，老实说现在域名重要性没那么高，考虑考虑 .studio 域名。

光能注册三字域名都难了，不管是 sgz 还是 sangezi 格式。建议找找自己姓名，用自己名字注册得了。

找律所啊，为啥来这问，而且十个纠纷八个是庭外调解的，律师会帮你搞定一切。

哇，IoT 之魂燃起来了，这玩意儿你买个 XX 派，声音传感器，可逆电机，python 写个脚本入 systemctl service 服务化。

@celaraze 总的来说，还是从数据库调优角度出发，分别从写入和查询去做优化，如果实在不行，按业务需求我蛮建议你非阻塞。

1 ，MyISAM 引擎。
2 ，频繁且大量写入，2 分钟全表更新一次。

不知道你的后端应用什么技术栈，我给一些可能的建议：
[应用] 避免单数据更新，尽量使用 `on duplicate key update` 语句。
[应用] 避免阻塞主线程，入队列写入，前端可给 toast 告知用户数据正在更新。
[DB] 索引，毋庸置疑，那列字段经常被查询、更新就加。
[DB] 查询时要尽量命中索引，少用 `!=` `or` `like` 啥的。
[DB] 分区表，100 / 1000 / 10000 条数据一个分区这样。

有个办法是你应用查询的过程，手动执行下，用 `explain` 检查下是不是这个查询经历了全表扫描过程，是的话就优化索引。

同 1L ，公司电脑别整这出，遵守规章。
如果实在要做，也不建议用代理转发，还是会留下流量特征。既然自己的群晖能访问，不如考虑下直接远程桌面、novnc 之类的解决方案。

可不就是静电吗，线材抗屏蔽不行、桌椅接地。