Join绝对是关系型数据库中最常用一个特性，然而在分布式环境中,跨分片的join确是最复杂的，最难解决一个问题。在SQL查询的局域中的尽量避免使用Left join或 Right join,而月Inner join。在使用Left join或Right join时，ON会优先执行，where 条件在最后执行，所以在使用过程中，条件尽 可能的在ON语句中判断，减少where的执行，同时少用子查询，而用join。Mycat目前版本支持跨分片的join,主要实现的方式有四种。全局表，ER分片，catletT(人工智能)和ShareJoin，ShareJoin在开发版中支持，前面三种方式1.3.0.1支持。
全局表一个真实的业务系统中，往往存在大量的类似字典表的表格，它们与业务表之间可能有关系，这种关系，可以理解为“标签”，而不应理解为通常的“主从关系”，这些表基本上很少变动，可以根据主键ID进行缓存，下面这张图说明了一个典型的“标签关系”图:
在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，考虑到字典表具有以下几个特性:
- 变动不频繁
- 数据量总体变化不大
- 数据规模不大，很少有超过数十万条记录。
鉴于此，MyCAT定义了一种特殊的表，称之为“全局表”，全局表具有以下特性:
- 全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
- 全局表的查询操作，只从一个节点获取
- 全局表可以跟任何一个表进行JOIN操作
将字典表或者符合字典表特性的一些表定义为全局表，则从另外一个方面，很好的解决了数据JOIN的难题。通过全局表+基于E-R关系的分片策略，MyCAT可以满足80%以上的企业应用开发。
全局表配置比较简单，不用写Rule规则，如下配置即可:
需要注意的是，全局表每个分片节点上都要有运行创建表的DDL语句。MyCAT借鉴了NewSQL领域的新秀Foundation DB的设计思路，Foundation DB创新性的提出了Table Group的概念，其将子表的存储位置依赖于主表，并且物理上紧邻存放，因此彻底解决了JION的效率和性能问题，根据这一思路，提出了基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上。
customer采用sharding-by-intfile这个分片策略，分片在dn1,dn2 上,orders依赖父表进行分片，两个表的关联关系为orders.customer_id=customer.id。于是数据分片和存储的示意图如下:
这样一来，分片Dn1上的的customer与Dn1上的orders就可以进行局部的JOIN联合，Dn2上也如此，再合并两个节点的数据即可完成整体的JOIN，试想一下，每个分片上orders 表有100万条，则10个分片就有1个亿，基于E-R映射的数据分片模式，基本上解决了80%以上的企业应用所面临的问题。
ShareJoin是一个简单的跨分片Join,基于HBT的方式实现。目前支持2个表的join,原理就是解析SQL语句，拆分成单表的SQL语句执行，然后把各个节点的数据汇集。
解决跨分片的SQLJOIN 的问题，远比想象的复杂，而且往往无法实现高效的处理，既然如此，就依靠人工的智力，去编程解决业务系统中特定几个必须跨分片的SQL的JOIN逻辑，MyCAT提供特定的API供程序员调用，这就是MyCAT创新性的思路——人工智能。
以后会提供更多高质量的API，简化分布式数据处理，比如内存结合文件的数据JOIN算法，分组算法，排序算法等等，期待更多的牛人一起来完善。
mycat后续的功能会引入spark和storm来做跨分片的join,大致流程是这样的在mycat调用spark,
storm的api把数据传送到spark,storm，在spark,storm进行join,在把数据传回mycat,mycat在返回给客户端。
