数据库架构演变
- 刚开始多数项目用单机数据库就够了，随着服务器流量越来越大，面对的请求也越来越多，我们做了数据库读写分离， 使用多个从库副本（Slave）负责读，使用主库（Master）负责写，master和slave通过主从复制实现数据同步更新，保持数据一致。slave 从库可以水平扩展，所以更多的读请求不成问题。
- 但是当用户量级上升，写请求越来越多，怎么保证数据库的负载足够？(主库的磁盘大小和磁盘I/O都受不了，把这个表分在多台数据库服务器里面进行写入）
- 增加一个Master是不能解决问题的， 因为数据要保存一致性，写操作需要2个master之间同步，相当于是重复了，而且架构设计更加复杂。
- 这时需要用到分库分表（sharding），对写操作进行切分。
- 分库分表对于客户端来说，操作的还是mycat，操作的都是一台代理服务器，操作的是逻辑库表，最终，分库分表映射到真实的库表。通过mycat代理服务器去select查询，可能在多个机器上查询，因为分库分表了。
库表问题
单库太大
- 单库处理能力有限、所在服务器上的磁盘空间不足、遇到IO瓶颈，需要把单库切分成更多更小的库
单表太大
- CURD效率都很低、数据量太大导致索引膨胀、查询超时，需要把单表切分成多个数据集更小的表
线程表的拆分算法：
- server.xml，schema.xml，分表的算法在rule.xml（根据时间把表的数据拆分到不同的表，或者是根据一致性哈希，或者直接取模，通过 Id（主键）和要分表的个数 进行取模）
需求原理
- 分库分表对于客户端来说，操作的还是mycat，操作的都是一台代理服务器，操作的是逻辑库表，最终，分库分表映射到真实的库表。通过mycat代理服务器去select查询，可能在多个机器上查询，因为分库分表了。
拆分策略
单个库太大，先考虑是表多还是数据多：
- 如果因为表多而造成数据过多，则使用垂直拆分，即根据业务拆分成不同的库
- 如果因为单张表的数据量太大（库里面没有多少表），则使用水平拆分，即把表的数据按照某种规则（rule.xml定义的拆分的算法）拆分成多张表（逻辑上还是同一张表）
分库分表的原则应该是先考虑垂直拆分，再考虑水平拆分。
- 垂直拆分： 优先考虑把库中，由于表过多而造成的数据过多，根据业务划分成不同的库，把不同的库部署在不同的机器上，进行的就是垂直拆分。
不是说用索引就快，数据太多，索引文件本身就非常大，用索引，首先要加载索引，加载索引也要花费磁盘IO，表数据田铎，增删改查都会涉及索引文件数据的修改，都是耗费时间的。
垂直拆分
分库分表和读写分离可以共同进行。
server.xml
配置了2个逻辑库：
