其实阿里有一个数据库的规范，那就是禁止三表以上的关联查询。那么目前为止我所接触过的一些项目，也的确是差不多的，有部分可以放宽到四表查询，但是超过四张表就不允许了，因为的确是会有性能影响的。除非是传统行业，对性能要求不是特别大，那么这个规约可以无所谓。那么绝大多数互联网公司也的确这么做，少数公司不按照这个规范呢也问题不大的。

为什么？

产品不允许：

• 阿里的OceanBase是只能两表查询，因为设计初衷就是如此，所以你不能违背。
• MyCat也只能支持跨库的两张表关联查询。
  所以产品本身不支持，你也不能强制做多表关联

MySql自身问题：

• 超过3表，那么如果优化力度做的不够，那么由于多表的嵌套查询，性能会极差（后面我们会有一个7-8表的关联查询，这个会做出来给大家看，性能也是绝对不好的）

（前瞻性）方便系统拆分：

• 比如用户和企业一开始在同一个业务中，那么可以做多表关联的查询，比如通过企业id获得所有的HR类别。但是如果在未来企业数据剧增，用户数据剧增，那么我们必定会进行服务系统的拆分，也就是我们目前的微服务，企业服务和用户服务，那么两个服务会由两个不同的项目组或者项目团队进行维护的，那么别的团队不会让你做直接sql的表关联脚本查询，肯定禁止，所以这个时候，我们都是通过业务层的代码来进行查询并且组装的。所以前期的表关联查询越少，那么后期的改造成本也就越低了，否则后期的数据迁移和改造会相当让人头疼。
• 甚至说，哪怕没有做服务的拆分，企业表达到几百万了，那么我们可能会根据地区进行水平拆表，这个时候原有的两表关联查询可能也会失效了，所以，不相关的业务表尽量不要做关联的查询。
• 数据库与其他存储介质的结合，很多时候有些业务的查询，是会结合redis+mongodb+elasticsearch+mysql这样多个存储介质共同查询后的包装结果，所以单单查数据库是满足不了业务的，数据库和业务之间往往都会有中间件，所以为了降低数据库的耦合，也是需要避免多表关联的。

所以禁止多表关联查询，说这其实也是为做分布式拆分做好基础准备。

公共表怎么查？

类似：省市区、系统参数、数据字典等都是属于公共数据，如果在平日里实现，那么都是在单系统里做查询，在分布式微服务中，往往把这些公共数据作为放入到资源服务中来实现，而我们现在就是这么做的，比如数据字典、行业树形结构，都是放在一个独立的微服务中使用。

假设用户数据会被企业服务、订单服务等调用，这个时候，其实用户数据会作为基础数据提供给其他服务使用，如此，其实也可以把用户看做是一个公共的数据，那么用户数据在被其他服务调用使用的时候就会通过rest接口来提供服务。其实在微服务之前，我们在早期涉及到类似场景的时候，就是通过httpclient来调用的，或者通过自研注册中心，把服务都注册进去，再调用用户服务的接口即可。

所以，其实涉及到公共资源的数据，哪怕前期是单系统同库，那么也是尽量降低耦合，尽量不要做多表关联的查询。