目录
一、数据库性能瓶颈及其解决方案
性能瓶颈
- 数据库连接数达到机器性能的瓶颈
- 表数据量过大，有些查询命中不了索引从而导致全表扫描
- 硬件资源本身的QPS(每秒的查询请求个数)和TPS(每秒的事务请求个数)的瓶颈
解决方案
- sql优化（避免多次查询，利用好索引）
- 缓存（redis，es）
- 建好索引（根据查询实际需求来建立索引）
- 读写分离
区别读、写多数据源方式进行数据的存储和加载。数据的存储（增删改）一般指定写数据源，数据的读取查询指定读数据源（读写分离会基于主从复制）
解决的问题：
1. 解决了数据库连接瓶颈
2. 释放了硬件资源限制（QPS\TPS） - 分库分表
对数据的库表进行拆分，用分片的方式对数据进行管理
1. 垂直拆分
解决问题
（1）解决了数据库连接瓶颈
（2）释放了硬件资源限制（QPS\TPS）
2. 水平拆分
解决问题
（1）表数据量大的问题 存储空间也解决了
（2）解决了数据库连接瓶颈
（3）释放了硬件资源限制（QPS\TPS）
二、MyCat的名词概念
逻辑库
对实际应用来说，并不需要知道中间件的存在，业务开发人员只需要知道数据库的概念，所以数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。如图一中，在MYCAT服务区中的db_user库，只是逻辑上存在的数据库，真正的数据来源还是来源MYSQL服务区中的两台实际的Mysql db实例。在Mycat中逻辑库在{MYCAT_HOME}/conf/schema.xml 用<schema> 标签定义。
逻辑表
既然有逻辑库，肯定将会存在逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表的数据来源，可以是数据进行切分后，分布在一个或多个分片库中，针对不同的数据分布和管理特点，我们将逻辑表又分为 分片表、全局表、ER表、非分片表。在schema.xml使用<table>标签对逻辑表进行定义。
分片表
是指那些原有的很大数据的表，需要切分到多个表，这样，每个分片都有表的一部分数据，所有分片数据的合集构成了完整的表数据，如图一种中MYCAT服务区的users表即是分片表，通过userID字段取模的方式进行数据的水平切分。如图中用户（users）表
分片规则
将大数据的表，切分到多个数据分片的策略。如图中 rule="mod-userID-long",名字为mod-userID-long引用的详细规则，将在MYCAT的rule.xml中（{MYCAT_HOME}/conf/rule.xml）中进行定义，具体定义规则如图
分片规则Mycat中内置了很多种，比如 按时间、按自定义数字范围、十进制取模、程序指定，字符串Hash，一致性Hash等等，总体可将这些分片规则分为离散型和连续型两种分片规则。离散型分片规则数据分布均衡，对数据的处理并发能力强，但是对于分片的扩缩容存在较大的挑战。连续性分片数据分布较集中，更符合业务特性，但是对数据的处理并发能力受限数据的分布，分片的扩缩容有更好的支持。
全局表
一个真实的业务系统中，往往存在大量的类似数据字典表的表，数据字典表具有以下几个特性：
- 数据变动不频繁
- 数据规模不大，数据量在十万以内
- 存在跟其他表（特别是分片表）有一点的关联查询要求
未了解决表与表的join查询，Mycat提倡大家将具有上诉特点的表通过数据冗余的方式（全局表的定义）进行解决，即所有的分片都有一份数据的拷贝。通过MYCAT对这样的表进行数据的操作时，数据的修改，新增，删除时，所有的分片数据都将受到影响。
ER表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat 中的 ER 表即是来源于此。根据这一思路，提出了基于 E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据 Join 不会跨库操作，如文中的案例，用户表是分片表，用户地址表与用户表之间存在一对多的关系，若通过分片规则，将用户表中的张三分在了分片1，则最好的数据存储方式是将张三的用户地址信息跟随张三一起分配在分片1中。这样一种表分组的设计方式是解决跨分片数据 join 的一种很好的思路，也是数据切分规划的重要一条规则。ER表中在schema.xml中使用<childTable>标签进行描述和定义，如图
非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。在schema.xml中具体的定义，可参见图
分片节点
大数据表进行数据切分后，每个表分片所在的数据库就是分片节点，狭义的理解可以认为一个DB实例就是一个节点，在schema.xml中使用<dataNode>进行分片节点的定义如图
节点主机
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机,为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机。在schema.xml中使用<dataHost>进行分片节点的定义如图
三、MySQL的主从复制
就是一种主备模式的数据库应用，主库（master）数据与备库（slave）数据完全一致，实现数据的多重备份，保证数据的安全。
MySQL主从复制原理
- 从库生成两个线程，一个I/O线程，一个SQL线程；
- i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；
- 主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；
- SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
四、MyCat的应用场景分析
应用场景1：MyCat读写分离（负载均衡）、主从自动切换
目前有大量MyCat的生产实践案例是属于简单的读写分离类型的，大多数读写分离的案例是同时支持高可用性的，即MyCat+MySQL主从复制的集群，并开启MyCat的读写分离功能，这种场景需求下，MyCat是最为简单并且功能最为丰富的一类Proxy，正常情况下，配置文件也最为简单。
需要注意的是：
主从复制是mysql自己实现的，mycat只是代理插件，它本身不能实现主从复制，只能实现了读写分离、主从切换、分库分表功能
具体的相关配置流程参考：https://www.cnblogs.com/kevingrace/p/9365840.html
应用场景2：MyCat分库分表
MyCat分表分库原理
MyCat里面通过定义路由规则来实现分片表（路由规则里面会定义分片字段，以及分片算法）。分片算法有多种，你所说的hash是其中一种，还有取模、按范围分片等等。在MyCat里面，会对所有传递的sql语句做路由处理（路由处理的依据就是表是否分片，如果分片，那么需要依据分片字段和对应的分片算法来判断sql应该传递到哪一个、或者哪几个、又或者全部节点去执行）
MyCat分片选择总结
- 根据业务数据的特性合理选择分片规则
- 善用全局表、ER关系表解决join操作
- 用好primaryKey让你的性能起飞
MyCat适用于哪些场景
数据量大到单机hold不住，而又不希望调整架构切换为NoSQL数据库，这个场景下可以考虑适用MyCat。当然，使用前也应该做规划，哪些表需要分片等等。另外MyCat对跨库join的支持不是很好，在使用MyCat的时候要注意规避这种场景
MyCat联表查询问题
- 用好ER表
- 善用全局表
- 使用注解
/*!mycat:catlet=io.mycat.catlets.ShareJoin */
select * from users u,employee em on u.phoneNum=em.phoneNum where u.phoneNum ='12345456454';
具体的相关配置流程参考：https://www.cnblogs.com/kevingrace/p/9365840.html