Mycat的分片join---江山如此多娇，引无数英雄竞折腰

join概述

Join绝对是关系型数据库中最常用一个特性，然而在分布式环境中,跨分片的join确是最复杂的，最难解决一个问题。
下面我们简单介绍下各种Join操作。
INNER JOIN
内连接，也叫等值连接，inner join产生同时符合A表和B表的一组数据。
如图：

LEFT JOIN
左连接从A表(左)产生一套完整的记录,与匹配的B表记录(右表) .如果没有匹配,右侧将包含null,在Mysql中等同于left outer join。
如图：

RIGHT JOIN
同Left join,AB表互换即可。
Cross join
交叉连接，得到的结果是两个表的乘积，即笛卡尔积。笛卡尔（Descartes）乘积又叫直积。假设集合A={a,b}，集合B={0,1,2}，则两个集合的笛卡尔积为{(a,0),(a,1),(a,2),(b,0),(b,1), (b,2)}。可以扩展到多个集合的情况。类似的例子有，如果A表示某学校学生的集合，B表示该学校所有课程的集合，则A与B的笛卡尔积表示所有可能的选课情况。
Full join
全连接产生的所有记录（双方匹配记录）在表A和表B。如果没有匹配,则对面将包含null。

性能建议

• 尽量避免使用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规则，如下配置即可：

<table name="company" primaryKey="ID" type="global" dataNode="dn1,dn2,dn3" />

需要注意的是，全局表每个分片节点上都要有运行创建表的DDL语句。

ER Join

MyCAT借鉴了NewSQL领域的新秀Foundation DB的设计思路，Foundation DB创新性的提出了Table Group的概念，其将子表的存储位置依赖于主表，并且物理上紧邻存放，因此彻底解决了JION的效率和性能问题，根据这一思路，提出了基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上。
customer采用sharding-by-intfile这个分片策略，分片在dn1,dn2上，orders依赖父表进行分片，两个表的关联关系为orders.customer_id=customer.id。于是数据分片和存储的示意图如下：

这样一来，分片Dn1上的