看下来，对 RDBMS 持反面意见的有三种。

一种是出于架构的角度，尤其是 scalability ，针对互联网大厂的应用场景，高弹性，高并发，数据量巨大，实时一致性要求低，确实知道自己为什么要去 RDBMS 。

一种是出于软工的角度，虽然也可能认同 RDBMS 的高级特性是好东西，但出于版本管理、RDBMS 迁移、CI/CD 的角度，还是选择把数据库当简单的存储表来用，这算是一种 tradeoff ，有舍有得。

还有一种是，没有专职 DBA ，广大“程序员”不懂 RDBMS ，所以把数据库当简单的存储表来用……在这里，程序员三个字可能被简化为这样一种气质（根据我在行业信息化工作中遇到的不少所谓程序员来看），大概自学或者在培训班学习了某门主流编程语言的基本语法，然后就在师傅的带领下进入业务系统的开发，有心于技术的可能会在实践中学习设计模式和软件架构，不是很有心的，可能会去钻研业务场景或者管理知识，慢慢脱离技术岗位。然而即使往高级技术路线走的这些 crud boys 其实技术体系是不扎实也不完整的，他们缺的不只是数据库知识，对操作系统（哪怕不涉及原理和内核，只是生产环境的 Linux 规范化使用和写脚本、业务系统所依赖的基础服务器软件比如 web server 的常用配置）、网络、编程语言（是说编译等，不是指会简单的语法）、信息安全也没有系统化的学习，甚至连培训班这样浮躁的系统化学习都没有。他们认为的开发、编程，在技术层面上就是指会用某种编程语言本身。悲催的是，大多数地方性的、行业性的小信息化公司里这样的程序员还要兼在客户的生产环境上做实施。我遇到过很多这样的乙方程序员甚至技术经理，真的很无奈。

@Fule 还有就是，我听到过一些案例，一开始去关系数据库，后来逐渐在应用层根据业务需求用 Java 代码来实现各种约束和抽象，相当于自己实现了关系数据库的部分功能。那问题来了，我是相信基础设施大厂和知名开源团队里专职做 RDBMS 的研发实力做出的实现呢，还是相信互联网大厂做秒杀出来流到行业信息化里的应用系统架构师们带着一堆北大青鸟、达内的 CRUD boys 在应用层做出的实现呢？

自研基础设施轮子，对个人成长很有价值……至于用这些基础设施的同事，饮水自知吧。

benchmarking 这种事，笑笑就好

建议楼主说说自己工作中所开发出来的系统的实际业务场景，是互联网还是传统信息化。

@onhao 因为阿里爸爸之类互联网大厂为社会输送的架构师们薪水高，话语权大，抱团刷价值观，所以在各行各业做传统信息系统的被他们的技术路线绑架了，很少会去考虑这些大厂推崇的技术路线是否适用于自己的场景。

一年嘛，经过的应用场景的毒打还远远不够。

可能互联网时代资本推动的公司增长和个人致富节奏让很多人并没有意识到按正常规律来说人在职场上的成长其实是很慢的。

以及，他们唯一知道的免费数据库是 MySQL ，这玩意长期以来在数据库高级功能上的实现确实比较烂，靠这些半身不遂的实现还真不如写到应用层。

因为他们以为他们做的实际并发不超过 10 个的信息系统要面对的应用场景都是阿里爸爸的双 11 秒杀……

六类线的正确姿势是用三件式或四件式六类水晶头

是一些只会实现业务逻辑而不去学习（甚至可能根本不知道有）操作系统规范的 24K 纯业务程序员的杰作。

现在写个 unit 来管理服务自启动又不是啥麻烦事，比以前 sysvinit 的年代方便多了，何必再执着于 rc.local 呢

用普通用户，给他 1⃣️配置 sudo 规则，只允许 nopasswd sudo 后执行重启某些服务的命令 2⃣️配置 authorized_keys 项，只允许执行指定的脚本，把 sudo 重启和前导后续操作写在脚本里

@EscYezi 对，所谓 Java 写 CRUD 写业务逻辑省事，大部分其实是在说 Spring……不严格地来讲（经不起咬文嚼字者抬杠），可以在某种程度上把 Spring 系列框架甚至 IDEA 的一些自动化功能看作是以 Java 为底层的 DSL……只就 Java 本身来说写业务有啥省事的，啰嗦致死。

离职大法好

有个“定理”说凡是能用 JS 重写的软件一定会用 JS 重写……
人家非前端圈子可能本来就在用“一些挺好的工具”，只是你熟悉 JS 生态，所以更了解用 JS 重写过的变种而已。

redis 里可以分库，见 select 命令。