mycat 变量的使用

1、我们现在按照业务将数据库垂直拆分成运单库（单表2000tps，6000W数据），快递员库（单表1500tps，100W数据），客户库（单表1500tps，1000W数据记录）；假设每个MySQL数据库单表不能超过2000W数据，单表不能超过1000tps。那么运单库则需要分成3片，客户库需要分成2片，统一由MyCat管理。如下图所示：

3、逻辑表在逻辑库下的表就是逻辑表。逻辑表可以分片，也可以不分片。orders表明显是要分片的表，但是在MyCat看来，他们虽然分布在不同的分片节点上（分布在不同的MySQL数据库上），但仍视为是同一个逻辑表，在同一个逻辑库里。2.1分片表分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。分片表都有自己的分片规则，根据分片规则确定分片。配置里面，如下配置：

5、非分片表一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。例如：意思就是快递员表不用分片，保存在test3这个分片节点上。对于非分片表的操作和对普通数据库的一样，因为不涉及到分布式数据库。

7、全局表一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性：变动不频繁数据量总体变化不大数据规模不大，很少有超过数十万条此暄跬烷记录。对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以Mycat中通过数据冗余来解决这类表的join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。数据冗余是解决跨分片数据join的一种很好的思路，也是数据切分规划的另外一条重要规则比如：运单状态信息字典表，只是注释每种运单状态，就是典型的字典表，与分片表orders为多对一的关系。对于全局表，所有的查询请求，只会发送到其中一个全局表分片上执行，所有的更新请求，会在每个全局表分片上执行。

9、像这种简单的从属关系一对n的表，我们处理起来很简单，一般将它们按照需要做join的键设为父子表即可。但是下面的场景很麻烦，比如快递员与运单就是多对多的关系，客户对于运单也是多对多的关系（一个收方，一个寄方）。我们既有快递员需要查看自己的所有运单的场景和客户查看自己所有运单的场景。相对的，我们也有查看一个运单涉及到的快递员还有客户的场景。customer表（客户表）以及courier表（快递员表）因为与分片表orders之间不做join操作，所以不用作为公共表。首先，关系表可以作为公共表，这样的话，涉及到与分片表的join操作没有限制，因为在每个分片，公共表都是完整的。但是，关系表的更新很频繁，我们可能不能忍受每更新一次关系表就跑到每个分片上都更新一次（性能，可靠性考虑）。那么作为运单的子表呢？那么查找一个运单涉及到的快递员还有客户就比较简单。因为根据运单号（也就是分片id）查询，MyCat就会根据分片规则给他定位到具体分片，而不是去按分片搜索。

10、作为快递员的子表也有同样的缺陷。还有一种方法，就是这种关系表同时作为运单和快递员的子表。但是这样，目前需要应用自己去做双写。MyCat目前还没实现这种。当然，我觉得这是一个我们自己可以根据需要改进的地方。MyCat中间件根据关系冗余表关系进行双写另外，究竟取哪种方法，都是从业务出发去考虑的。在这里，如果从快递员出发去查找以及从运单出发去查找的业务压力差不多大的话，那么最好就采用关系表同时作为运单和客户的子表这种方法。然后将快递员和运单的业务独立，每个业务应用都去维护自己的关系表，同时通过消息队列来保持关系表之间的一致性。这样也不失为一种方法。