那个 CPU 密集型任务本身才是关键。
如果都是单台机器的话，方案 1 和 2 功能没有什么太大区别，如果是我选择方案 2，快，然后就可以喝咖啡了。
如果方案 1 是多台机器各种运行密集型任务，那完全和方案 2 又不是一个层面的问题了啊

小而精。功能虽然不强大，但是通常够用。

这些楼主是照着某位同事总结的吗？有些好具体啊。

的确，特别是去有钱但是 IT 部门没什么事的客户，很多小问题数据库完全可见处理的，一定要上 XXX 项目。我曾经处理过一个客户，处理 XXX 一定要上 spark，但是机器就 3 台老服务器，内存 16G...无所谓的，你可以想一下为什么这个破机器要上 Spark ？达到目的皆大欢喜
解决问题有的方法简单，有复杂的，有些看似简单实际运维复杂，有的还有利益关系。甚至有时候刚好研发同学最近看了某些工具或者方案，于是就用了。
我现在觉得最终能够稳定解决问题的方案，至少不算差，至于其他的不太重要了。

坚持不挖屎坑给别人，也从不接别人的屎坑。

几年前折腾过几次，钱的钱没有时间浪费的多。现实毒打后明白，技术很难改变什么，代码更不是什么生成资料。有些看是切入点的场景，实际上可能并不存在。下次如果我再搞的话，不管怎么都要快速上线验证并试错，不行立马撤，时间成本太高了。

差不多这个价格，只补偿房屋建设的钱。我老家房子拆迁，可以拿钱，也可以选择在县城买房，补贴 2k 每平。

《谭浩强 c 语言程序设计》无出其右

4 张 1kw 的表之间还要 join ？ n 比 n 的 join 吗？

密集型的计算，核心数还是核心数+1 。偏向于+1，因为现实中 CPU 太快了，再密集的计算都难免有内存带来的延迟，增加一个来充分利用 CPU 。
如果只是为了应用，得到合适的线程数，那实际情况远不是理论上一个公式那么简单，这个场景跑 benchmark 得出是最靠谱的。
但是看了你这个问题描述，好像你或许不是需要多少个线程数，而是定位目前性能上不去的瓶颈是什么？还是先 profile 找到瓶颈点再去找解决方案吧

盲打。没有刻意练习过，只是打字多了形成的肌肉记忆一样的东西，如果突然问我：C 键在键盘位置，我一下子很难回答的，需要动手模拟敲一下才知道位置的。
不是盲打的，我觉得要么敲得少了不熟练，要么看键盘成了类似肌肉记忆一样不经意的习惯了。

1.上策，尽快溜掉，避免和他合作，省时省力。
2.中策，让直接领导知道并认同你的看法，让领导去沟通。就算沟通无果，后面也好甩锅。
3.下策，你说沟通无果。那首先划分好模块，但是你们是一个功能，唇亡齿寒吧。加强单测确保功能，只要他的功能没问题，屎山又奈你何。
4.地下室策。大哥喝茶，你的功能我帮你写

一定要生成代码才能解决吗？生成的代码可不好维护呀

其它场景不太清楚，但是在数据处理的领域。如果单论写入性能，结论是 mmap 不会直接明显提升写入性能。因为不管什么写法瓶颈在 IO，只要写入速度到了磁盘 IO 上限，就再也无法提升。看了好多上面测试结论都有不准的可能，IO 性能的 benchmark 是不太容易的，需要用一定的技巧才行，因为系统数据缓存的原因，很容易最终测出的不是磁盘 IO 速度而是内存的速度。

推荐考研。不过即使是研究生，对于普通员工来说，能力要比学历更重要。

lowcode 是在断部分边缘开发者的后路。lowcade 这个概念本身一直存在，只是最近直接被单独拿了出来了。企业上云断了很多边缘运维人员的后路。如果企业应用 lowcode 后，同样要断很多边缘开发者的后路。
没有银弹，lowcode 没有任何实际的技术革新，lowcode 能断多少人后路，关键看能解决多少核心的复杂业务逻辑。
为什么说目前是断边缘开发者后路呢？因为目前 lowcode 只能解决功能需求相对固定的需求。企业软件本身不产生实际价值，解决对应问题才发挥了价值。因此对于要解决的问题本身才是软件的关键。对于企业核心问题本身才不关心是不是 lowcode 。只有那些不着边的非核心业务，本身不创造太多价值的软件，才会关系软件开发和维护的成本，这个时候可能会考虑 lowcode 。