@Richard14 #37

其实也不单纯的是 mysql 横向扩展困难 mysql 这么弱鸡的数据库去抗企业行业应用那种低 qps 负载，只要少用锁别干死锁了，都能扛得住，搞行业软件的跟搞对海量普通用户业务（我只是习惯叫互联网替代这种业务）的互相理解很难。

我们定义的大系统 crud api server 是 35kQPS(包含缓存操作)，他们定义的大系统是 80 人开发 700 多个模块编译后二进制文件都 900MB 然后 15qps ，对数据库性能的理解我们是优化到单查询 0.0035 秒他们是 1 秒能出结果就行。


十五年前吧，我也搞过 oracle ，写企业商业软件简单到离谱，写医院的业务系统，20qps 都是高并发的超大大医院了
oracle 这玩意只要搭起来集群，给足了海量内存，四路服务器或者当年小型机堆上去，也不用怎么设计索引，看着差不多觉得可能用得到就上一个，剩下的 oracle 自己就能给你优化好，这就是搞商业软件行业软件的逻辑，跟面对庞大公众用户的基本思维就不同


比如，最近朋友公司在搞信创国产化，要绕过供应商把一个三甲特大型医院的一个大业务系统数据库从 oracle 替换成人大金仓，我听着直摇头，金仓就是魔改的 pg11 ，这怎么能行，一个特大型三甲那门诊量和住院医嘱量，oracle 的牛逼查询自适应优化能力，换弱鸡山寨 pg 怎么行，结果一换试了下，还真行。在中间件下了个性能检测记录 SQL 防止语法不兼容，结果 24 小时系统峰值读查询 qps45 ，医院上班工作时间平均读查询 qps15

---

关于讨论，V2 早就这样了，所以这些年我都不爱吱声了，顶天在 tg 群里遇到感兴趣的能说两句。

之前说的都是大家好理解的形象的常识，不说人话的不搭理就是了，更深入的不搞这个根本接触不到的你发了也没人看
要不就是真搞这个的还有问问问从来不自己研究，就差让你手把手教了

五六年前的 V2 讨论技术问题，还是可以只提供思路，现在，要么是一群啥也不懂的瞎参和，要不就是希望你手把手给他搭好才能证明你说得对的。。。