目前互联网企业的大多数应用，似乎不应该使用关系型数据库

目前互联网企业的大多数应用，似乎不应该使用关系型数据库。

这听起来是一句暴论，不是吗？

但是问题在于，现在很多互联网企业，尤其是国内大厂（当然，小厂更严重），只是将数据库当作一个存储数据的介质。其中阿里尤甚。对于关系型数据库辛辛苦苦开发的高级功能，锁、并发读写、触发器、存储过程，那是一个也不用。我听说阿里还禁止使用外键，以优化性能，我不知道是不是真的。

所以在很多互联网企业那里，关系型数据库退化成了单纯的表格。他们成天在上面建索引，完全不按照范式设计数据库，拼命搞冗余字段，整天纠结SELECT *是不是性能比SELECT 1性能差这种问题，就为了提高一点性能。

结果本来应该数据库帮他们做的事情，他们全移到 Java 上，人工管理。本来应该依赖于数据库自身的优化，他们人工搞一堆冗余字段，上消息队列，用 Redis，人工搞了一套缓存方案优化性能。怪不得互联网大厂都那么喜欢 MySQL——因为它一开始这上面提到的“高级功能”都没有，只能当作表格使，而且快得简单粗暴，这很符合他们的需求。

那问题就来了。他们都这么辛苦地自己建了一套逻辑去干关系型数据库应该干的事情，把关系型数据库当表格使，为啥不自己开发一套文件系统，直接读取硬盘簇？就算没这个能力，自己造个适应自身业务的小数据库也要比整天去调 MySQL 方便得多。就算再不济，也可以在 MySQL 基础上做一层封装，比如直接把 Protocol Buffer 序列化往 MySQL 里装，再做个中间层做性能优化。这不比直接在 Java 那边手撕业务好得多？

这就是矛盾的地方。关系型数据库源自关系代数，它要做的就是通过那几个声明式的 SQL 语句，让你在不用关心具体数据库执行流程的情况下，快速地得到数据。结果现在一众大厂可以说对数据库自己的性能完全不抱信任，通过各种奇淫巧计，以一种极其 Ugly 的方式侵入底层去，自己去做本应该让数据库做的事。我不觉得这很聪明，我只觉得整天纠结 MyBatis 和SELECT *与SELECT 1的人很傻逼。

关键问题是，很多小企业还以跟随大企业的技术栈为荣。在日访问量不过数万的网站上也跟着用 MyBatis，面试必问高并发。这是很奇怪的。我以为工具造出来的目的是为了让人省心，而不是为了让人不得不去适应工具，把工具拼命改造以适应自己的需求——那你就根本不该用这个工具。

我认为西方互联网公司倾向于使用 NoSQL 是有这个原因的。实际上照我看来，NoSQL 本应最先在国内得到大范围应用。由于双十一的存在，阿里应当是全世界第一个遇到这样规模超高并发量的公司。而在这种情况下，阿里本应考虑是否因为关系型数据库的限制而无法处理更高的并发量，以此思考 NoSQL 方案的可行性。结果是，阿里选择继续深造 MySQL，开发了更多的 MySQL 调优奇淫巧计，成功处理了更高的并发量。这某种程度上体现了中外的思维差异——我们善于压榨已有工具的潜力，而西方常常在发现当前工具不适合时，使用甚至发明新的工具。

后来 Google、Meta 等遇到了类似的高并发情景，发觉当前的关系型数据库模型不能很好地支持日益增加的并发量与互联网上缺乏结构化的、杂乱无章的信息，因此使用并发明了许多 NoSQL 方案，比如著名的 BigTable。

我当然并非只是一味地夸赞“西方公司具有创新性”这种不能更公知的发言。只是国内技术的这种单一性，经常让我奇怪——我们这么大一个国家，这么多完全不同的业务需求，真的应该全都使用一套技术栈解决问题？我们在已有技术上的压榨并不一文不值，相反这些是西方很多企业做不到的。但是当手上的锤子不好用时，为什么我们很少考虑换个工具，而是看什么都像钉子？很多技术都有足够的理由在国内诞生与发展，只可惜我们现在的做法仅仅是追随着国外大厂的研究方向，然后做个 Chinese Version，仅此而已，不再有更多的创新了。