直接介绍概念太枯燥了，还是拿个和背景篇相似的例子介绍
业务场景：客户完成下单，快递员接受并更新运单状态，客户可以随时查看运单状态的任务。一票快递可能有多个子母件。
因此，我们需要建立如下表： 
我们现在按照业务将数据库垂直拆分成运单（3000tps，4000W数据），快递员（1500tps，100W数据），客户（1500tps，4000W数据记录），运单表和客户表均按照某种规则分片，平均分成两片。然后假设他们都通过MyCat统一管理。
应用访问MyCat，根据之前所述，应用感知到后台只是一个数据库（假设这个库叫SF，里面有运单相关表，快递员相关表和客户相关表）；访问MyCat，结果应该如下面所示 
虽然其中的表可能存在于不同的库，但是表面上，他们属于同一个MyCat实例中的同一个逻辑库
orders表和orders_fee明显是要分片的表，但是在MyCat看来，他们虽然分布在不同的分片上，但仍视为是同一个逻辑表，在同一个数据库里。
分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。分片表都有自己的分片规则，根据分片规则确定分片
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat中的ER表即是来源于此。根据这一思路，提出了基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据Join不会跨库操作。
表分组（Table Group）是解决跨分片数据join的一种很好的思路，也是数据切分规划的重要一条规则。
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性：
变动不频繁
数据量总体变化不大
数据规模不大，很少有超过数十万条记录。
对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以Mycat中通过数据冗余来解决这类表的join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。
数据冗余是解决跨分片数据join的一种很好的思路，也是数据切分规划的另外一条重要规则
根据之前的描述，我们可以推断出，对于分片表的修改和查询，如果是按照分片字段进行查找的话，则请求会被转发到一个分片上。如果不是按照分片字段的话，就会把请求发到每一个分片上进行查找。所以，分片字段的选择比较重要！对于全局表，相当于在每个分片上有一份相同的复制，修改请求会在每一个分片上执行，但是查询只会落到一个分片上。所以，全局表尽量是不会改变的而且是需要和分片表做Join操作的，如果经常改变或者不需要做join，最好还是做成非分片表。
先抛出了这几种逻辑表的概念，大家先有个印象。现在我们结合具体实际讨论如何决定表的类型。
首先，orders表可定是分片表。orders_cargo表是子母件表，一个order可能有多个子母件，所以，最好把orders_cargo作为orders的子表。
这种情况下，orders与orders_cargo按照对应键（就是子表按照哪个键与主表的哪个键对应进行分片。比如orders_cargo就是order_id与orders的id对应。这是以order_id与orders的id进行join结果就是对的）join结果也是正确的。 
像这种简单的从属关系一对n的表，我们处理起来很简单，一般将它们按照需要做join的键设为父子表即可。
但是下面的场景很麻烦，比如快递员与运单就是多对多的关系，客户对于运单也是多对多的关系（一个收方，一个寄方）。我们既有快递员需要查看自己的所有运单的场景和客户查看自己所有运单的场景。相对的，我们也有查看一个运单涉及到的快递员还有客户的场景。
customer表（客户表）以及courier表（快递员表）因为与分片表orders之间不做join操作，所以不用作为公共表。
首先，关系表可以作为公共表，这样的话，涉及到与分片表的join操作没有限制，因为在每个分片，公共表都是完整的。但是，关系表的更新很频繁，我们可能不能忍受每更新一次关系表就跑到每个分片上都更新一次（性能，可靠性考虑）。
那么作为运单的子表呢？那么查找一个运单涉及到的快递员还有客户就比较简单。因为根据运单号（也就是分片id）查询，MyCat就会根据分片规则给他定位到具体分片，而不是去按分片搜索。 
但是相应的，客户查看自己所有运单的场景就比较慢，因为请求是发送到每一个分片上查找。 
作为客户的子表也有同样的缺陷。
还有一种方法，就是这种关系表同时作为运单和客户的子表。但是这样，目前需要应用自己去做双写。MyCat目前还没实现这种。当然，我觉得这是一个我们自己可以根据需要改进的地方。
另外，究竟取哪种方法，都是从业务出发去考虑的。在这里，如果从客户出发去查找以及从运单出发去查找的业务压力差不多大的话，那么最好就采用关系表同时作为运单和客户的子表这种方法。
本文出自 “张哈希的技术博客” 博客，请务必保留此出处http://zhxhash.blog.51cto.com/10645572/1743714
原文地址：http://zhxhash.blog.51cto.com/10645572/1743714
