很多人说 sam 的卡是装逼。觉得高人一等。
作为每个月大采购一次的。sam 和大冰箱是绝配。他本来的定位就是你一次性大量采购品质的平均线是基本一致的。反正我去山姆买很难买到品质差的，不能说特别特别好。他下限高啊。缺点就是有的东西太多了，饮料动不动就是 24/36 一箱。买个薯片饼干要论箱买。这个其实不友好，我就是想尝尝而已。

相反，超市理应是同样的走量，高质的。但超市为了短期利益，都是面向大妈大爷们，成了菜市场。这么说吧，超市早上去和晚上去你买到东西品质是不一样的，山姆晚上 8 点的东西和早上 8 点的东西，品质基本一致。

山姆也自己做出了自己的拳头产品，国内有一个算一个，除了胖东来，一个能打的都没有。

山姆的牛肉还是那句话，他一定不是最好的，但是下限最高的。去菜市场买，要靠自己眼睛和运气，山姆你哪天去，拿的牛排都是 ok 的。想吃牛肉？ 10KG+的大包够你吃一个月的，算平均价格比超市还便宜。

我家的冰箱基本去一趟山姆冷藏就满了。

牛肉卷，跟风仿造的一大堆，味道嘛。。吃了的都知道。

如果是可以迁移库。。有一说一，迁移 pg 保平安。。最少一个分区下去就能解决你大部分问题。。

1.cursor 法，上亿的数据，就算你 20 一页吧，产品经理麻烦你来给我翻到第 1234567 页谢谢。。。其实都这么多数据了。total 返回一个固定值估计都没人发现。。哈哈哈哈哈
2.分区。哦。不好意思。。窜台了。mysql 没分区。那就只能分表了。
3.外置表。也就是其他的解决方案，这就可以随意脑洞大开的想方案了。问题是很容易成另一坨屎山。任何新技术的引进都会导致复杂度的上升，我相信绝大多数用 mysql 到几亿了才想到分页怎么搞的 team ，玩 clickhouse 好，玩 es 也罢，都是会踩你没踩过的其他的雷的。

持续重构。没有第二条路。其他都是扯蛋。如果没有投入持续重构，动不动就是，这个功能稳定了，不能动，代码不能改。吧啦吧啦。。这必定成为一个新的 shit 山

都几亿数据了。你要说没备份库我是不信的

nas 啊。。。。再不济。。接个外置硬盘在 dp 口上。
真想不明白怎么可能有 500G 的数据经常要查看。。

说的轻轻松松是有前提条件的。仅仅是业务查询，非聚合查询。聚合分析别说上亿了，上千万，可能就得考虑上 olap 的分析工具了。

另一方面，你都上亿的数据了，还是需要分析的。4c 16G 是不太小了点。这个成本是可以计算的。

1.clickhouse 集群。4*16 集群 x3.
2.mysql 把硬件往上面拉三倍。

从哪个角度看都是 2 成本更低。除非你能做到 1 是动态的，但投入的隐形成本又是另一回事。

换句话说，我个人认为绝大多数的场景，堆机器就够了。除非有数据分析团队资源，全靠研发自己出方案，实在得不偿失

这倒是，有 gpt 加持，后端狗半天就会撸前端了

反正作为运维，每个新项目我都要怼一次后端开发 leader：不许给我搞微服务，你就单体。

单体也需要运维，都让研发搞就是逗闷子的。只是真不需要一堆运维了，我一直认为国内公司，90%有且只需要两个运维。搞微服务？那就看架构吹牛逼吹多大了。

我怼得最多的一句：高并发？你自己试过本地 mysql 1000 万数据集两到三层良好索引的 sql 效率吗？没有？没有你扯犊子的因为性能横向扩展？

如果有 apple vision 。那就只有这个。如果没有。憋着

组件是为需求服务的。。
你这相当于我要一个超级牛逼一统天下的组件库。等于没要求。

按回车按快了。。
另一方面肯定不是一蹴而就，前面网关做分离工作，迁移一批网管流转新流量过来一批。反正这么大的规模，就算是看起来是差不多的业务逻辑，但凡错一个，估计得祭天。

从写单元测试开始。上千的表。接口也差不多上千了。你怎么保证重构完了一摸一样的结果和逻辑？

折腾时间够买一个带云功能的血压计了。。

说到这个就来气。。。一哥们说 vue 很好用。一定要用 vue ，我说了 n 次，我公司 4-5 个前端，全是 react 。。这 vue 的屎山谁来吃？不行，那就是 vue 框架添加第一，硬要上。我就低头了，我就低头了，我就低头了。。恩。最后这坨屎山还是我来吃。我能说什么。。。

不算大佬。但是。当一个跟你一样想法的人放飞自我的去做了。擦屁股的大概率还是自己啊。。你骂骂咧咧拍拍屁股就走了。得，我还要在自己不熟悉的自己不熟悉的屎山里面翱翔。我自认自己拉的也是屎山，请问，既然都是屎山，我自己拉的和别人拉的，我就一定要为了顾及想法，捏着鼻子去吃别人拉的？

@prenwang 这就跟阿里云的 java 军规一个道理。先对齐颗粒度，打通底层逻辑。完全的无厘头限制。

这么说吧。。如果一个编辑器没有 vim 模式，那只有垃圾堆适合他