那些 PUA 的，其实是给你们送育儿福利，老实人还是太善良（法盲）了

这几个定义确实不怎么好，即使是英文原版，加上定义的细节，非常容易让人记混。反正如果有人面试问我这几个，我八成回答不准确。

我喜欢用自己的分类总结，比这三个定义更容易记忆而且更全面。如下：


这几个工程问题根本原因的共性：查询缓存的 key 不存在。主要有两类：
1. 传入的查询的 key 参数本来就不存在。例如传错参数、攻击时黑客随便弄的空 key 。
2. 业务上曾经存在该 key 、但是设置了有效期、查询时过期了。

造成工程问题时的另一个维度就是 key 的数量：
1. 少量 key
2. 大量 key

key 不存在的原因、key 的数量维度结合起来的四种情况。

完整详情，欢迎评论：
https://gist.github.com/lesismal/3640d2a74db3eaf303bb8d40ecd0de05

@sthwrong #6

> 海量数据这俩都不是银弹，都得拉队友支撑

对，我在主贴中就说过了。

> 现阶段，pg 的队友可能更多更强大

普通数据量级，pg 功能丰富很多业务非常好用，这个我在主贴里也说了



但是我见到的几次 V 站上 pger 们的现象，有点盲目相信 pg 了，不区分业务量级数据量级和场景，一味贬低 mysql 。
这样会造成很多错觉，中小项目做得风生水起，大项目直接拉垮，尤其是早期阶段的 OLAP 甚至业务逻辑重度依赖 pg ，导致大项目发展起来后的重构成本高太多。
所以我并不是说 pg 不好，也不是说 mysql 比 pg 好，而是应该懂得如何合理选型、不要盲目追捧和吹嘘。

对于这种海量数据场景，mysql 的劣势甚至成为项目发展生命周期中的优势，比如 OLAP 不友好、干脆早期就少用它搞 OLAP ，比如存储过程不行、干脆不使用它的存储过程，而是把这些都诉诸于拉队友的方式解决。这些不便利，在业务量级剧增需要重构时，反倒成为优势。

当然，多数人的工作内容并不涉及这种海量数据场景，用 pg 足够爽，挺好的，但是没必要盲目捧 pg 贬 mysql 。

@guiyumin #1 我是聊技术观点，您如果不聊技术、上来就 who care 不太合适吧？纯技术选型的观点，跟 uber 倒闭不倒闭也没关系的，请先理清自己逻辑


@sthwrong @kapr1k0rn pg 确实在进步，但海量数据场景 pg 不是银弹、甚至很多人依赖 pg 的 OLAP 导致数据量真的增长后很难迁移，uber 的 blog 主要是衬托海量业务场景传统关系数据库仍然不足、十年来 pg 的进步不假但是解决不了海量性能问题，所以不存在十年前就不合时宜的问题

49 年退 d