@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 被人钻漏洞下蛊，拿去挖矿了

@delectate #5 讲道理，游戏膨胀那么狠那是高清贴图的锅，要兼容性能跨度那么大的那么多显卡，整不同精度的贴图是成本最低的做法了（没有之一）！

推荐还是 VS CODE 或者 jetbrains 的 Pycharm

sublime 真的可惜，作为一个 win+mac+linux 三地原生的文本编辑器（应该不是 webview 套壳），其本身的优质体验却因为社区生态建设没起来落后了，导致用户越来越少，很多 package 的作者也转移阵地去其他编辑器 /IDE 上开发了，sublime 的众多好用插件都陷入年久失修或者烂尾状态。

然后 sublime 社区落后的原因，很可能跟它官方压根就没想做好开发者社区，没当 package 生态建设是一回事，甚至就是有意打压社区建设，这些因素有关。

像我最近也想自己写些 sublime 的包自己先用用看，结果找文档找到官方的 package development doc ，是只有一页 html 的残缺品你敢信？简直是要啥没啥！它官方好像生怕别人通过 package 文档应该有的各种 api 逆向出来功能实现一样！
甚至在它官方文档开头，就写着你要想看到更多内容，就请去参看非官方文档，就差把直接开摆写在脸上了。

我就想开发一个它的包，只调用一些 sublime 基础的 view 、window 的功能，还得自己搜索各种社区非官文档、博客教程、so 问答，这跟 vscode 官方有手把手教你做插件的教程形成天壤之别。

官方的具体骚操作中，像 run command 的 command 名称的设定，sublime 居然是用的约定（官方文档没有任何地方写过这个），而不是你给 command 名赋值。它默认就用你设置的 class 名称（还必须是大驼峰写法，且不能有连续的大写字母，比如"OK"）解析成带下划线的 command 名。
这尼玛这么基础的 run command 功能的 command 名称设置，你官方文档居然都只字未提，这让想入门的开发者从哪儿琢磨起啊！！！真就当社区文档、社区问答是你的牌面啊！我最开始知道这个被恶心了一下午，真实瞬间就不想给 sublime 写脚本了。你官方都摆烂，还指望其他开发者给你扶正了？