最近看到一个让人哭笑不得的面试场景！面试官问："为什么SQL语句不要过多的join？"结果候选人直接回怼："面试官，你们没用过好用的数据库，你也不懂数据库！"

这个回答简直太真实了！现在的互联网公司是不是都被"大数据"洗脑了？动不动就照搬阿里巴巴的规范，完全不考虑自己的实际情况！

什么？日500万就叫大数据了？

我面试过几个所谓的"互联网云原生+原教旨主义者"，张嘴闭嘴都是大数据！不管三七二十一，一律分库分表分布式！

我问他们："你们表最大多少行？"

答案是：日500万！

500万算个毛线大数据啊！连HDD的MySQL性能退化点都够不着！这些人是不是对数据量的概念完全没有概念？

现在的互联网人动不动就说要"效率"，说视图（view）每次查询效率很低。我问他们怎么解决，他们说："我创建个表，定期把结果数据更新进去。"

这不就是物化视图（material view）吗？！既然知道这个概念，为什么不直接用物化视图呢？是否可以用material view只JOIN增量的部分，然后再Merge进去总量的结果表呢？

JOIN真的有那么可怕吗？

明明一句查询可以搞定的东西，非要上一套大数据引擎！况且，在绝大多数情况下，数据库的运算效率比你自己写的都要高！

只要有JOIN的必要在那里，不在数据库里做那就得在应用里做。在应用层面做，你要先付出IO的成本！如果真的因为"数据量大"而不去JOIN，那这个IO成本一定不会低！

应用程序所使用的优化手段（细化JOIN的范围、只处理增量的部分等），绝大部分情况下对数据库也适用！把这些逻辑放在数据库层面做，可以直接节省下IO成本！数据量越大，这个效率提升就越大！

真相揭露！JOIN慢的真正原因

所谓的JOIN慢并不是JOIN本身慢，而是这帮人每一次都按全量数据去处理！但他们自己写应用逻辑的时候，又按增量的方式去更新（例如ETL）！

你用增量去和全量比，有点不公平吧？

如果是借着JOIN的名义做着各种各样复杂业务处理的事情，这就属于你的问题了！别用锅甩给数据库！

互联网人的知识体系过时了！

现在的互联网人知识体系还停留在HDD年代，完全不顾现代NVME SSD的发展历程！

对于绝大多数公司（剔除阿里巴巴、腾讯等某几家头部），从成立到倒闭积累的数据量都不会超过40T！

与其搞那么多分布式，用几倍的运维管理成本来换取一丁点的读写性能提升，还不如直接上NVME SSD阵列！先把单机容量和IO性能顶上去，方案更简单、更直接，管理成本更低！

哪怕是最低级的消费级SSD组成的阵列，立刻获得8~20倍以上的读写性能提升！

现代数据库没你想的那么弱！

单表500G，全库20T，现代数据库在NVME SSD加持下轻轻松松不费吹灰之力！

说这些只想表达一个观点：现代单体数据库没你们想的那么弱！吹上天的伪分布式数据库也没你们想的那么万能！

绝大多数场景下，你们的数据量也远远远远远没到达能把分布式OLAP系统用出性价比的程度！

你们基础不牢固，不分场景滥用、误用导致的锅，别甩给数据库！

对于各位互联网云原生、高并发、高性能、大数据、超融合原教旨主义者，奉劝一句：好好学习数据库基础知识，不要盲目跟风！

技术选型要根据实际业务场景来定，不是什么都要上分布式！不是什么都要避免JOIN！

500万数据就说大数据，真的让人哭笑不得！现在的SSD性能你们了解过吗？现代数据库的优化能力你们测试过吗？

别再人云亦云了，踏踏实实做好技术选型，这才是一个合格程序员应该有的态度！

你们觉得呢？在评论区说说你们遇到过的类似"伪大数据"场景吧！