目录
Mycat官网
1、数据切分
将放在同一个数据库中的数据分散存放到多个数据库主机上，以达到分散单台设备负载的效果。数据切分可分为垂直切分和水平切分：
1.1、垂直切分
适用范围：垂直切分规则简单，适合业务逻辑简单，清晰，耦合度低，多表之间关联查询较少的场景；
a、根据业务模块切分，如系统中存在资产、产品、风控、交易四个模块，都在一个数据库中，现在为了提升单库的性能瓶颈，根据业务模块拆分为4个数据库；
b、单张表字段数据过多切分，将一张表的几十上百个字段根据关联型 提取为几块，分割为几张数据库表；
优点：拆分后业务清晰、拆分规则明确；
系统之间整合或扩展容易；
数据维护简单；
缺点：部分业务表无法join、只能通过接口方式解决、提高了系统的复杂性；
受每种业务不同的限制存在单库性能瓶颈、不易数据扩展和性能提高；
业务处理复杂；
垂直切分是按照业务模块来划分的，仍会存在单库的读写与存储瓶颈，此时需要水平切分；
阿里开发规范：500w数据量，分表；3年内达不到这个量，系统初建时不要考虑分库分表；
1.2、水平切分
单张表数据量过大，将数据按照某种条件拆分到多台数据库主机上面；
如当天表、30天内的数据表、历史表；或者根据id取模分布到对应数据库上；
优点： 不存在单库的读写和性能瓶颈；
拆分规则合理的话、不影响单库join查询；
提高了系统的稳定性跟负载能力；
缺点：拆分规则难以抽象；
分片事务一致性问题；
数据多次扩展难度和维护量极大；
跨库join性能差；
两种数据切分方式的共同缺点：
分布式事务的问题；
跨节点join难度;
跨节点数据合并、排序问题;
多数据源管理问题;
由于数据切分后关联查询的复杂度会大大提升，Mycat中提及一下几点需要谨记：
第一原则：能不切分尽量不要切分
第二原则：如果要切分一定要选择合适的切分规则，提前规划好
第三原则：数据切分尽量通过数据冗余或表分组(Table group)来降低跨库join的可能性
第四原则：由于数据库中间件对数据Join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表Join；
2、Mycat中的一些概念
2.1、Mycat
数据库中间件，介于应用和真实数据库之间，进行数据处理与交互的中间服务。
以前是应用直接连接数据库，现在是应用先连接到Mycat，Mycat根据查询sql条件分配到不同节点数据库查询数据，然后组装返回给应用；
2.2、逻辑库
可以看做一个或多个集群构成的数据库集合
2.3、逻辑表
真实的表，可以是数据切分后的每个分片表，也可以是单一的一张表；
2.3.1、分片表
单张表数据量过大，会切分成多张表，每张分片表持有一部分数据，多张分片表合起来是完整的数据；
2.3.2、非分片表
单张表数据量不大，并不需要分片存储的表
2.3.3、ER表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat 中的 ER 表即是来源于此；
数据量过大时进行分片，子表的数据和父表的数据都需要分片存储，将子表和父表所关联的数据分在同一个节点数据库上，保证数据进行Join操作的业务复杂度最低；
2.3.4、全局表
类似于字典表的一类表，数据量不大，处理各种业务逻辑也经常会关联到的，进行数据冗余操作，所有节点都存储一份这样的表，降低关联查询复杂度；
2.4、分片节点
dataNode、最小单位
2.5、节点主机
一台机器可能会放多个分片节点，这台机器就是节点主机
2.6、分片规则
rule、数据切分时，一张大表中的数据需要切分为多张分片表，一定要提前设计好分片规则；
2.7、全局序列号
sequence、保证存储在多个节点的数据ID唯一；