如何避免多表联查

好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受！

目录

方式一、添加冗余字段

方式二、小表广播

方式三、建立集中的服务

方式四、基于数据中心

---

跨入21世纪，数据呈现了暴增的阶段，以往数据结果的获取方式都是以多表联查为主而获得的结果，可是在大数据的时代，数据暴增的情况下，再如此往复的使用多表联查，势必会对性能造成一定的影响，那么如何才能够避免使用多表联查，而又能达到预期的效果呐 ？

方式一、添加冗余字段

所谓冗余字段，就是在主要的信息上，添加上一些辅助的字段（比如搜索框中的搜索关键字，列表中的列表项等，这些信息都是由其他主体或业务上来的），用添加列的方式，来替换掉使用left join 或 inner join的方式获取数据，实现列表数据或报表数据的展示。
这种方式是违背了数据库三范式的设计的，可能只是满足了三范式中的第一范式或者满足了第一，第二范式。这种方式在实现上，需要在数据录入的时候，将所需的信息都得到，并放入到相应的列上。

适用范围 : 单体服务，分布式微服务，DDD方式设计的领域服务中心均可，即便是进行了分库分表，也同样适用。

缺点: 信息录入时候，需要将要使用到的信息都获得到，并将其放入到相应的字段上去，在并发时候，会存在性能问题。

 

方式二、小表广播

在业务开发中，之所以需要进行多表联查，是因为很多数据是动态可变的，只是在主表中存入了关联表的关联主键，在需要进行数据展现的时候，通过关联主键，得到关联表的信息，进而进行数据的拼装和处理，最终通过服务的方式体现出来。

这种处理方式，主要是针对主表数据量大，但是关联表数据量小，并且关联表的数据变化频繁的情况下，在分布式的微服务系统中，使用这种方式。

难点是 : 所谓的小表，其实就是另外一个服务中的副本表，但是这个副本表的信息要远远小于副本的主体表，这样的情况下：主体表的信息同步到副本表，就是一个很重要的事情。

既要保证数据的准确性，还要保证数据的及时性，对实现有着比较高的要求。

适用范围 : 分布式微服务分库情况下，列表上的信息需要从其他一个或几个微服务数据库中而来

缺点 : 实施难度大，数据同步要求高。

 

方式三、建立集中的服务

建立一个专供的微服务，背后有一个专门的数据库，通过某种同步机制。把各种需要联合查询的信息同步到这个库，然后这个微服务就专门提供这类联表查询，适合实时性要求不高的分析场合。  

这种处理方式，主要还是使用使用sql的方式去解决问题，即使用数据库引擎去处理数据关联的事情。

难点是 : 关联数据的实时同步，同步的准确性，以及服务的稳定性，对实现有着比较高的要求。

适用范围 : 分布式微服务分库情况下，列表上的信息需要从其他一个或几个微服务数据库中而来

缺点 : 实施难度大，数据同步要求高，关联性管理梳理。

 

方式四、基于数据中心

数据中心可以通过各种数据同步工具（datax，kettle，kafka等）将关系型数据库中的数据抽取出来，放到hdfs上去，可以根据关联性存到类sql的hive上，或者是列式数据库hbase上去，然后再通过api的方式向外提供数据服务，当然也可以按照关联关系将数据放入es上去，基于es来提供数据服务。

基于数据中心的这种处理方式，可以比较好的实现数据服务的功能，但是也有其自己的不足，主要体现在实时性上。

难点是 : 如何保证数据的实施性，如何建立好数据的关联性。同样既要保证数据的准确性，还要保证数据的及时性，对实现有着比较高的要求。

适用范围 :  单体服务，分布式微服务，DDD方式设计的领域服务中心均可

缺点 : 需要会大数据处理的人才，需要更多的服务器资源，需要更多的项目投入（时间），需要保证数据的准确性，一致性，及时性。

实时要求高的场合，上大数据，流处理，同样也是相关关联的数据以流的方式进行计算得到你用关系数据库必须联表才能得到的数据。

 

其他的方式：如在内存中进行分页搜索查询，使用CQRS方式，或者是其他；总之都可以解决数据联查，数据显示的问题。

至于究竟需要使用哪种方式，这全看技术官的决策，个人推荐：在数据量大的时候，可以使用第一种字段冗余的方式，
即便是以后分库分表，也不会出问题，而且还能很好的解决问题，所需的成本也是最小的，而且也是最容易实现的方式。

当然其他的方式也可以选择，这就要根据实际情况去定了。

 

处理这类的问题，没有什么银弹，还是要具体问题，具体对待，这里就是说下解决思路！