平常得用 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 的公司，国内还有其他公司自研引擎吗？）

好家伙，笔记相关推荐 /总结帖要成日经了，我前几天才看到一个什么个人知识库的建立

我怎么感觉，解决那张图就是只用加几个查询数据时附带的元信息呢，比如原始数据的更新时间 /行数 /版本之类能识别先后顺序的信息？
写缓存的时候既然要覆盖，就不能先让 redis 查一下会不会有覆盖的情况，然后再比较一下数据的数据更新 /获取时间，判断是否缓存的旧版本数据再来覆盖吗？
有哪个大佬能用更现实的情况说明一下？

要是有 github 项目能研究一下就好了，这全局反代让人看不出破绽，确实很牛（不过可能黑产的人研究了之后会有其他安全问题？）
不过速度跟直接梯子没法比，是因为通道被很多人平分的缘故嘛？

借楼问个事情，你们有遇到过 pycharm 起的 python 脚本任务，CPU 调度优先使用小核，小核不满大核就围观的情况吗？

来来，店铺都帮你找好了
https://store.lizhi.io/site/products/id/484

@LemonK #7 装了 redis 嘛？
ssh 破解是一个问题，安装的一些软件 /环境的漏洞是另一个问题。
我最近公司就碰到 redis 被人钻漏洞下蛊，拿去挖矿了