主要现在的智能还是需要人作为大部分中间层去对接过度，属实是生太早了，或者说资本太贪婪，逮着个能赚钱的新概念就使劲用它薅消费者

等到不那么弱智能的机器人作为中间层出世的时候，你可以在任意接口 /统一入口输入智能指令，那时候才是真智能。
反过来想，智能家居其实也就一个帮你定时定点定条件干活儿的电子管家而已。

看看清单革命
把你的多线程队列里的第二名及以后的任务都丢一个你不想想起的地方（记忆宫殿；或者强制自我暗示“现在只看得到第一项，只记得住第一项”），只在第一名任务完成后才去检索和更新队列
我个人的话用此法配合一些白噪音能快速进入心流状态（。
只不过，根据个人情况，很容易累（。

@CharlesQin #20 左右边缘滑动返回上一级🤣因为这个我是坚定的安吹，反观苹果的产品逻辑绝对无法在这一点上达成自圆其说

不是，vscode 有大内存也卡啊？我就没有遇到过不会卡的 electron 应用啊😂？

还好看到能有人站出来反驳 win server 性能问题的一些言论，不然还真以为 V2EX 沦落到路边酒馆的水平了。
另外搜索 win server 市占率，对没见过世面的会有惊喜 /吓——这还是在 win server 贵的出奇的许可证费用下

@vvjyun318 关键是明明可以强制应用分屏浏览，让应用拖个小窗出来都行，但就不；就算两边都大黑边我都能忍，但就不。
怕不是要跟 iphone 死活不跟进左右边缘滑动退出返回上一级的功能一样，要成万年老梗:<

平常得用 python 操作 Excel 出大量统计报表的路过
因为 WPS 必须企业版才能装宏插件，还是用额外下载的一个奇奇怪怪的安装包来装，vba 运行效率还低，还可能不兼容 pywin32 ，所以那台专门生产 excel 报表的机子不可能转 WPS
不过如果其他人用 office 软件，一律推荐 WPS ，仅因为免费，功能对小白易上手
倒是你们说的 office 安装问题，如果用 365 正版的话，现在仅需要下载一个安装启动器就行，和 visual studio installer 类似但啥都不用选不用操作，挺简洁方便的啊，下载完就直接使用了，现在打开三大件速度也比以前快得多（死活下载不下来的就不用提了，网络问题不在这个讨论范围

看完只想说，哪个行业颠覆者快来收了微信这个祸害吧！
再也不想用微信接收工作消息了，企业微信也不行！

从微软的方面考虑，他们肯定也不愿意给 wsl 这种不稳定的黑魔法应用兜底，至少在能稳定当成生产工具卖钱之前不愿意。
在此基础上，如果要拿来当工具卖钱，微软怕不是还要额外维护一条 [能稳定当作生产环境的运行在 wsl 上] 的 linux 分支

@asmile1993 亲，你看懂了先好不？
cte_1 里 distinct 已经按照 [user_id ，月，日，时] 去重了，cte_2 里的 partition by 用的 [user_id ，日，时] ，两者只相差 [月] ，所以 lag 只能取到不同的月，懂了不？
还不懂也不用回我了，你自个儿测试去

@asmile1993
你注意看，我那段 sql 最开始的 cte 里有 distinct （或者你用 group by 也可以），已经按照所需的时间粒度去重了，所以肯定是拿的是排序后之前月份的数，已去重了不可能拿到当前月份

@dongfuye1 谢谢！

@dongfuye1
懂你意思了，感谢解惑。
不过我又冒出来两个 db 侧的疑问😂
——如果 db 知道 v2 在 v1 后，或者 db 就是以这个顺序接收到的（这里不管 db 是否是分布式），那么为什么不把 update_time 放在 db 侧生成？如果放在 db 侧生成，会拖累多少性能？
——如果 db 不知道 v2 在 v1 后（这里假定了 db 是分布式，接收 v1 、v2 的先后顺序对不同节点也不同；不同节点接收到 v1 和 v2 时，因为节点的时钟相互间没法精确校准而导致不知道 v1 、v2 谁先谁后），也不会根据应用程序传进来的不靠谱 update_time 来判断，那么最终是怎么权衡保留 v1 、v2 哪一个值呢？靠投票取众数？平手取随机😂？

不过上面俩问题归到根源还是一个问题，也即
如果 db 能有一个最终稳定写进硬盘的数据版本 v2 ，那么肯定能从 db 给到应用端继而给到缓存端“为什么最后保留了数据版本 v2”这个依据，那么缓存端在判断保留哪个缓存时也可以根据这个依据来判断。为什么没有这么做？

这个问题可能跟 op 你的解决方案无关系，因为你的方案应该是从应用端出发的。我之前没考虑过这种思路，学习了，周末有空研究一下

@lookStupiToForce
补充一下，这里面的 [月] 得是 年月，就是类似这种 '2021-01' 包含年份形式的月份，否则会出问题

最快速的方法需要窗口函数，理论上扫一次表即可，不会回表二次查询，除非内存不够要写临时表，否则只剩内存计算

partition by 的条件根据需要的时间粒度去取
下面以需要{日-小时}一致为例

with cte_1 as
(select distinct user_id, 月, 日, 时 from table where ...), -- 在这里扫表一次
cte_2 as
(select user_id, 月, 日, 时,
lag(月, 1, null) over (partition by user_id, 日, 时 order by 月 asc) as last_月, -- 这里演示怎么抓到上一个相同 [日-小时] 记录的月份
case when lag(月, 1, null) over (partition by user_id, 日, 时 order by 月 asc) = 月 - 1 then true else false end as flag_1
case when lag(月, 2, null) over (partition by user_id, 日, 时 order by 月 asc) = 月 - 2 then true else false end as flag_2
from cte_1)
select * from cte_2 where flag_1 and flag_2;

如果需要{日-小时-分-秒}一致，
只需要把上面 distinct 后的和 partition by 后的 [日, 时] 替换成 [日, 时, 分, 秒] 即可

@dongfuye1 #11 首先感谢解答
但即便是分布式的情况，我还是不懂 db 里如果有一个 update_datetime 这种字段，传出来给到缓存判断有什么困难，即便是分布式 db ，也不影响步骤 4 里拿到的 update_datetime 比步骤 1 里拿到的晚。
除非遭遇这样一种情况，就是分布式 db 里，初始的 v1 的 update_datetime 已经比写入 v2 时的 update_datetime 还要晚。但这个时候 db 系统本身就出了问题（比如因为延迟问题，两个进程先后把 A 和 B 两种值写入了 db ，我们逻辑判断需要的是 B ，但是 DB 最后写入的是 A 且只存了 A ，不是普通意义的脏写却可能发生），应该查 db 系统的写程序逻辑、db 内部缓存逻辑、事务提交逻辑，而不应该在服务查询时的缓存阶段亡羊补牢，靠延迟更新或者其他啥绕路的法子补救
当然如果你非要说往 db 里加 update_datetime 会要人命，那我没话说了
op 提到的具体实现原理和过程还没有研究，算个小论文了，收藏了以后再慢慢看

记个笔记
这玩意儿查了之后知道叫“分布式操作系统”“Distributed operating system”，知乎 2020 年有过讨论但应者寥寥，主要迄今业界也没啥好的解决方案的样子。
看来只能继续做梦了（。

有时间研究肯定是好的，不过得看你公司游戏客户端用的技术栈或者你以后想发展的方向再决定。
像虚幻和 unity 都对 c++有要求（ unity 虽然只支持 c#，但可以通过调用 dll 支持 c++；有 c++基础 c#上手也容易得多），其他游戏引擎不清楚（不过除了这俩和部分用 cocos2d 的公司，国内还有其他公司自研引擎吗？）