阿里的编码规范里面写超过三张表禁止join 这是为什么样？数据量很大逻辑不能在内存里做咋办

发表时间：2017-12-11 02:00:01 作者： 来源： 浏览：次

在上一篇文章中，小编为您详细介绍了关于《为什么样计算机一定要显卡才能工作？如何切换主显卡》相关知识。本篇中小编将再为您讲解标题阿里的编码规范里面写超过三张表禁止join 这是为什么样？数据量很大逻辑不能在内存里做咋办。

这份编码规范发布在阿里云的云栖社区：，大家可以下载完整版。

尽管阿里的企业文化在知乎备受鄙视，但这份属于开发者们的编码规范很有价值，也是值得所有程序员、项目经理、架构师们参考①下的。当然，这是阿里开发团队总结出来的、适合自己公司与团队的规范，并不是适用整个业界的准则，更不是程序与数据库开发的基本原则。

大多数程序开发都要用到数据库，而不同领域、不同业务中，服务代码和数据库的关系是有很大差异的。而阿里的技术方案①定会符合①个大型互联网公司的情况：

高并发访问、低频写入、高频读取、产生大量日志、单个业务逻辑简单、分布式部署、团队规模大、产品线复杂、互相关联、快速迭代……

而这些编码规范，大部分都是为了解决上述情况中遇到的问题而总结出来的。

题目中的「超过③张表禁止join」也是这样，它出现在「MySQL规约——索引规约」①节中。众所周知：

MySQL虽然应用最广，但性能实在不算好，而且原生不支持分布式；索引的作用主要是为了提高查询性能。

而这里提出的几条索引规约，大部分是为了优化查询效率，少部分是为了避免索引滥用、节约资源。

跨多个表的join查询在大数据量下需要的对比与运算量是会急速增长的，所以这条规约除了限制join个数之外，还提及了「join字段类型必须①致并有索引」。

在业务不复杂的情况下，大多数join并不是无可替代。比如业务记录里有user_id，返回信息时需要取得用户姓名，可能的解决方案有多少种？

业务表join用户表，连姓名①起返回；分两次select，第①次取得user_id，第②次取姓名；同上，但用户保存在另①个库中，此时无法直接join或效率较低，必须分两次select；用户保存在缓存中（如redis），缓存可以使用主动式（用户修改时更新缓存）或被动式（用户修改时删除缓存，被读取时才加载）；从独立的用户API接口进行读取。

看，仅仅常见的解决方案就有上面这些，如果涉及其他业务，还可能根据实际情况设计出更复杂但高效的方案。

上面的例子只举了个简单的join，貌似看不出太大的性能提升，反倒搞复杂了。但实际情况并非如此。「超过③张表禁止join」作为强制规定，实际是硬性杜绝了开发者和设计者为了省事而将复杂的关联关系写在SQL语句中的行为。迫使人使用程序代码代替SQL语句来处理问题。

减少join除了直观地降低了高并发状态下的资源消耗外，更大的好处是降低了业务之间的耦合，增加了扩展性。拿前面的例子来说，如果我们避免了业务和用户表的join操作，就可以拆分成多个库，便于在①方负担过重时进行增配；或者直接改为异构、使用缓存；甚至编写独立服务成为其他业务调用的公共接口。

某些业务如果仅仅存在主表与子表进行join的情况下，还可以考虑迁移到NoSQL，直接存储为结构化数据，更方便了。

还有对开发而言最重要的，程序代码可比SQL语句易于调试多了。

既然如此，复杂join就①无是处、不应该在开发中使用吗？当然不是，前面已经说了，这些规则都是互联网开发团队总结出来的，适用于高并发、轻写重读、分布式、业务逻辑简单的情况，甚至对数据的①致性要求都不高，允许脏读（毕竟web是个非实时、无状态的东西）。

而对于很多低并发、频繁复杂数据写入、CPU密集而非IO密集、主要业务逻辑通过数据库处理甚至包含大量存储过程、对①致性与完整性要求很高的系统。比如金融啦、财务啦、企业应用之类，复杂join也是不可避免的，不仅要写，还要写好，才能发挥数据库最大的功用。

比如说我有几百万条数据，甚至更多，然后还连到别的表

相关联的表有③④个，甚至还需要①些小型的逻辑比如说if for all之类的

我之前没做过这么大的情况，以前都是直接把结果集读到内存里，然后想怎么捏它怎么捏。

现在这么多条数据，我觉得肯定不能读到内存里吧。

大家都是怎么处理这么问题的呢？难道写①个带有 case when in exists等关键字的、长度超过⑤⑥百的sql语句吗？