上面的思路都是通过合理的数据分布避免跨库关联查询，实际上在我们的业务中，也是尽量不要用跨库关联查询，如果出现了这种情况，就要分析一下业务或者数据拆分是不是合理。如果还是出现了需要跨库关联的情况，那我们就只能用最后一种办法。
系统层组装
在不同的数据库节点把符合条件数据的数据查询出来，然后重新组装，返回给客户端。
排序、翻页、函数计算等问题跨节点多库进行查询时，会出现limit分页，order by排序的问题。比如有两个节点，节点1存的是奇数id=1,3,5,7,9……；节点2存的是偶数id=2,4,6,8,10……
执行select * from user_info order by id limit 0,10
需要在两个节点上各取出10条，然后合并数据，重新排序。
max、min、sum、count之类的函数在进行计算的时候，也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。
全局唯一ID全局唯一id的问题，前面已经说了，水平分表之后，需要考虑全局唯一id设计问题。
多数据源的问题分库分表之后，难免会存在一个应用配置多个数据源。
另外，数据库层面有可能会设计读写分离的方案，也使得一个应用会访问多个数据源，并且还需要实现读写分离的动态路由。
而这些问题在每个应用系统中都会存在并且需要解决，所以为了提供统一的分库分表相关问题的解决方案，引入了很多的开源技术。
分库分表解决方案目前市面上分库分表的中间件相对来说说比较多，比如
Cobar，淘宝开源的分库分表组件，目前基本上没有维护了。
Sharding-Sphere，当当开源的一个分库分表组件，已经捐献给了Apache基金会
Atlas， 奇虎360开源的分库分表组件，也是没怎么维护了
Mycat，从阿里cobar升级而来，由开源组织维护。
Vitess，谷歌开源的分库分表组件
目前很多公司选择较多的是Mycat或者Sharding-Sphere，所以我重点介绍Sharding-Sphere的使用和原理。
对于同类技术的选择，无非就是看社区活跃度、技术的成熟度、以及功能和当前需求是否匹配。
关注[跟着Mic学架构]公众号，获取更多精品原创