公众号：杨建荣的学习笔记 · 作者：r13笔记第73天 · 发布：2017-09-05 23:37:03 · 原文链接

   MySQL的使用场景中，读写分离只是方案中的一部分，想要扩展，势必会用到分库分表，可喜的是Mycat里已经做到了，今天花时间测试了一下，感觉还不错。

关于分库分表

    当然自己也理了一下，分库分表的这些内容，如果分成几个策略或者阶段，大概有下面的几种。

最上面的第一种是直接拆表，比如数据库db1下面有test1,test2,test3三个表，通过中间件看到的还是表test,里面的数据做了这样的拆分，能够咋一定程度上分解压力，如果细细品来，和分区表的套路有些像。

  接下来的几类也是不断完善，把表test拆解到多个库中，多个服务器中，如果做了读写分离，全套的方案这样的拆解改进还是很大的。如此来看，数据库中间件做了很多应用和数据库之间的很多事情，能够流行起来除了技术原因还是有很多其他的因素。 

分库分表的测试环境模拟

  如果要在一台服务器上测试分库分表，而且要求架构方案要全面，作为技术可行性的一个判定参考，是否可以实现呢。

   如果模拟一主两从的架构，模拟服务分布在3台服务器上，这样的方案需要创建9个实例,每个实例上有3个db需要分别拆分。

   大体的配置如下：

  master1: 端口33091  
(m1)slave1: 端口33092
(m1)slave2: 端口33093
   master2: 端口33071
(m2)slave1: 端口33072
(m2)slave2: 端口33073
  master3: 端口33061
(m3)slave1: 端口33062
(m3)slave2: 端口33063

  画个图来说明一下，其中db1,db2,db3下面有若个表，需要做sharding