在上次的学习中搭建了一个简单的通过中间件使用多套MYSQL 进行数据存储和查询的实验。一个中间件尤其是对多套物理库进行处理的工作方式势必要面临至少两点问题。

1  分区主键的设置

2  多表之间的联合查询下发

分区主键的设置就包含了，如何对数据进行拆分，而在一个项目中数据库中的表也会呈现几类

1  分片表，及与分片表相关的使用同一分片规则的关联表（统称分片表）

2  全局表，在每个分片的物理MYSQL数据库中的全量表

3  素人表，开玩笑了，其实就是这张表可能和具体项目无关的一些表。

那上篇文字中的三个文件，在分区表里面起到什么作用还是要说一下的，下图是上一篇的文字截图

这里主要使用schema.xml 和 rule.xml 这两个文件， 其中schema 包含了连接的MYSQL 的服务器以及相关的具体的数据库，例如你这个库里面的表到底是分片表还是全局表，或者是素人表等等都是在schema.xml里面决定的。

而最终和分片有关的就是rule规则，其中包含了到底哪个表的字段作为分片键，分片的方法，以及分片方法里面的细节（例如你的取模是几呀）

下面举例分片表，全局表，素人表在schema 中的简单配置

分片表 <table name="test1" dataNode="node1,node2",rule="sharding-by-hash2"/>

一个表在 NODE 1 NODE2 进行分片的表

全局表<table name = "company" primaryKey="ID" type="global" dataNode="node1,node2" autoIncrement="true"/>   在NODE1 和NODE2 全量存在的表

素人表 <table name = "logs" dataNode="node2"/>  仅仅在NODE 2 存在的表

当然还有一个叫子分区的分片表。

基本上DBLE中间件包含了这个数据库上的表在逻辑分区上的大部分可能性。

而如果本身对分表不感兴趣的情况下，DBLE 也可以作为读写分离的一个中间件来用，满足各方面的需求。

其中读写分离中的规则是

1 SELECT 语句不能在事务中

2 SELECT for  update 语句不能有

2 SELECT for  share mode 

这三种的select 语句也不会发送到读节点，而只能在写节点处理，所以如果有的读和写之间存在事务的关系，例如订票业务，下单业务等等确认是否有库存或者座位是否已经卖出，先查后UPDATE 的方式，封装在一个事务里面是不会走读库的。

在DBLE 中可以对节点中的读库负载的进行设置，默认读库在不配置中是均衡进行压力均衡的，如果在某个节点配置了 weight 而其他节点不配置，则不配置的节点为 weight = 0 不承担读的负担。目前读节点Crash后会将读请求发送到写节点。

同时学习中文档建议不建议一个MYSQL实例中有多个分片，这样做的坏处是当一个查询没有条件的情况下，会将一个查询变为N个查询对应N个分片，那一个MYSQL实例中有多个分片的情况下，一个实例承受的的查询书就是“假设分片是 N”，则一个查询对应这个MYSQL的实例就是 N ，如果是并发的情况下，则就可能造成灾难性的问题。