最近好几次看到有人说脚本语言 ORM 牛逼，强类型语言 ORM 垃圾。

保持清醒一点好吗？弱类型 ORM 当然轻松了，但是你失去的是编译期检查，失去的是强类型系统规范安全保障等一系列优势。
ORM 只是让你获得了舒适区，就像刷抖音，很舒服，你获得了一些东西：比如你不太需要去思考 sql 语句如何写出来。但是你同时也大大减少了对不同数据集合处理的思考。如果是大表大数据集合，往往都是性能相关、对业务性命攸关的。当你习惯了只要 ORM 能实现业务逻辑的时候，扪心自问、有能力配得上去做海量业务海量数据的业务吗？随便一个 API 里的 ORM 生成的 sql 就可能把数据库卡住导致大量业务请求失败！
按照金字塔模型，这种层次的 CURDer 是开发者的主力群体，任何一个人保持在这个水平层次上都没问题，因为并不是每个人都需要去对高并发高性能这件事情负责，多数商业场景，随便写写都可以搞定。但是，如果是自己安于停留在这个层次，就不要出来拿性能说事、标榜我 PHP 或者我 Java 或者我什么语言很强了。或者如果自己想提升自己的技术境界技术能力，就不要把着眼前这点脚本语言的简单性能测试或者什么来对比了，参考我上一条回复，咱也不吹谷歌 golang 团队那两外老爷子和其他年轻一代的众神、因为其他语言的作者团队们也都是众神，但各个大厂的技术管理层跟进什么放弃什么是很有参考价值的、因为他们直面的就是工程领域商业战场，他们可不是傻子。

PS：我自己写 golang ，我也仍然经常说 golang 性能怎么也无法赶上 c/cpp/rust ，因为我也写 c/cpp ，我淘空了心思优化 golang 也仍然赶不上 c/cpp

建议 OP 多想想吧，那么多大厂跟进 golang ，人家的 CTO 、技术管理层，哪个不是背景闪耀、身经百战，哪个不是血雨腥风海量业务里杀出来的？你以为这些技术领头羊们都是弱智都是吃素的嘛。。。

另一个侧面，阿里当年从 LAMP 转型，放弃 PHP 到 Java 的时候跟 golang 也没关系，如果 PHP 给力还需要还 Java 吗？

别说什么 PHP 现在性能也提升了，语言指令性能的提升并不是性能的全部，只是一部分，甚至只是一小部分。
能写同步代码的编程语言，HTTP 服务的性能瓶颈多数时候都是慢 IO 占用系统线程。
能写异步代码的编程语言，又要面对 callback hell ，比如传统的 c/c++，脚本里 nodejs 。
简单 CURD 你不需要 RPC 、不需要各种基础设施的慢 IO 操作、你的 API 通常也不是海量并发，这时候一切看上去都还很美好，因为你搞定了业务、性能指标也并不比其他语言差，开发效率贼高，心里贼爽。
但是，如果接口里需要这些同步代码进行慢 IO 操作、并且会导致直接阻塞了线程，又遇到海量业务场景高并发的时候，系统线程数量瓶颈、并发度有限、会导致几何级的响应性能降级、请求积压，这时候如果跟那些异步非阻塞语言相比（ golang 这种同步代码但底层 runtime 实际上是异步非阻塞、不需要因为系统线程数量为 N 就只能并发处理 N 个请求，本质上也是异步非阻塞，但让用户可以写同步代码），差距就下来了。
所以别被那些语言指令性能的 benchmark 灌醉。

语言慢 IO 占用系统线程不只是 PHP ，Java 非 Netty ，或者 Java Netty+同步方式操作慢 IO 基础设施之类的，或者其他语言类似的方式，也同样有这些瓶颈。

@lifei6671 #4

> 是 Go 开发，QPS 几千，后端只部署了 4C+8G 的容器 70 台。😂

我怎么感觉你这是在黑 go 。。。QPS 才几千就 70 台 4C+8G 。。。
这么多 4C+8G ，如果瓶颈，猜测是你们数据库、缓存等基础设施瓶颈，日志量大 io 慢，或者其他这些语言无关的架构、系统瓶颈。否则我怀疑应该是你们 golang 代码写得太渣了。。。

对比下 golang 本身的能力：
https://www.v2ex.com/t/945827

嘲笑 golang 的主要群体是 curd boy ，这部分人对性能没有太大需求。
而且这些人中绝大多数自己都不熟悉 golang 相关的轮子就嘲笑 golang 开发效率低，按这个道理如果他们没写过 php 、ruby 、nodejs 、python 、c#等语言、则同样可以嘲笑那些语言效率低。

随便嘲笑吧，其实我们这些务实的 gopher 也真的不喜欢这帮人来 go 捣乱，看见他们把简简单单逻辑写成某些其他语言风格冗长的设计模式屎山，我们也很烦的。

所以，对于这部分人，请你离开，千里之外，咱们各自安好，各自都有美好的未来。

vsc 喜提 java250w

写 c/c++ 最大的感受不是成就感，而是 [ faster and faster, most of the things under my control ]，性能像利刃、针尖一样锋利无比，加上控场的感觉，确实很爽
其他脚本、带 runtime 的语言都没这感觉，比如 go 、再怎么优化性能都做不到 c/c++ 那样锋利的快感

@sakuramanstein #9

我猜是因为 “碳同位素定年法”

刷题这个场景，如果还考虑性能（在所有答题者里的排名），那 go 确实不太适合

目测：最近 v2 流行自爆🧐

我认识一哥们，三年六家倒，自己一直造轮子，从小菜鸡到现在游戏主程，水平已经非常棒了

拿飞机当图床，这思路，佩服，赞一个！

目测队列不适合解决你的问题：
1. 队列适合解耦、削峰，适合不需要响应队列处理后的结果的请求
2. 队列不能减少处理数量，如果请求需要响应、积压后响应延迟更高甚至超时

要提高性能又不至于让大量请求超时：
1. 数据库前面加缓存
2. 操作缓存和数据库的前面，加 singleflight 、合并同类请求、减少不必要的数据层操作
3. 如果真的量大，仍然需要软、硬件扩容

缺少业务的实际细节，先列这几条吧

第二个问题，考虑下每条数据有更新时、按你们的规则计算一下该数据对应的结果值，如果线上业务频率不高、直接原表加字段、频率高则新表 id 关联。
新功能先跑一轮任务把每个字段按照当前值计算出来存入新的字段、为了避免线上业务与任务并发冲突、该任务执行时建议停服、或者有更新的相应接口暂停访问。

这样就可以避免每次全表、需要时一条 sql 查结果字段即可，如果规则比较复杂、一个结果字段不够、可以多加几个字段

好像主要是滑动、列表展示那些动画的滑动速度设置得更快，让眼睛以为整个网站很快。点开某个、子页面并没有很快的感觉