《MyCat权威指南》学习笔记

1. OLTP和OLAP

对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。

（1）OLTP

联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。

（2）OLAP

联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。

2. 关系型数据库和NOSQL数据库

（1）关系型数据库

关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的 oracle、DB2、MS SQL Server 和 mysql 都属于这类传统数据库。

（2）NoSQL 数据库

NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。

3. 数据切分

指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）
上面，以达到分散单台设备负载的效果。

（1）垂直切分

根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的垂直（纵向）切分。
优点：
• 拆分后业务清晰，拆分规则明确；
• 系统之间整合或扩展容易；
• 数据维护简单。
缺点：
• 部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度；
• 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高；
• 事务处理复杂

（2）水平切分

按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的水平（横向）切分
几种典型的分片规则包括：
• 按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；
• 按照日期，将不同月甚至日的数据分散到不同的库中；
• 按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中

优点：
• 拆分规则抽象好，join 操作基本可以数据库做；
• 不存在单库大数据，高并发的性能瓶颈；
• 应用端改造较少；
• 提高了系统的稳定性跟负载能力。
缺点：
• 拆分规则难以抽象；
• 分片事务一致性难以解决；
• 数据多次扩展难度跟维护量极大；
• 跨库 join 性能较差。

但共同的特点缺点有：
• 引入分布式事务的问题；
• 跨节点 Join 的问题；
• 跨节点合并排序分页问题；
• 多数据源管理问题。

针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，
在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；

4. MyCat是什么

(1)一个强大的数据库中间件。介于数据库与应用之间，进行数据处理与交互的中间服务。(2)支持用MySQL客户端工具和命令访问。
(3)支持用MySQL原生协议与多个MySQL服务器通信。
(4)用JDBC协议与大多数主流数据库服务器如MySQL、SQL Server、Oracle、DB2、PostgreSQL、MongoDB等通信。
(5)用作读写分离、分库分表、容灾备份、多租户应用开发等场景。
(6)适合1000亿条以下的单表规模。

5. MyCat的表

（1）逻辑表

读写数据的表就是逻辑表。

（2）分片表

是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。

（3）非分片表

一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表

（4）ER表

子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据 Join 不会跨库操作。

（5）全局表

所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。 字典表具有以下几个特性：
• 变动不频繁；
• 数据量总体变化不大；
• 数据规模不大，很少有超过数十万条记录。

6. 多租户解决方案

数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个
独立或者是共享的物理库，常见的如阿里云数据库服务器 RDS。

（1）独立数据库

一个租户一个数据库，用户数据隔离级别最高，安全性最好，但成本也高。
优点：为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
缺点：增大了数据库的安装数量，随之带来维护成本和购置成本的增加。

（2）共享数据库，隔离数据架构

即多个或所有租户共享 Database，但是每个租户一个 Schema。
优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。
缺点：如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；如果需要跨租户统计数据，存在一定困难。

（3）共享数据库，共享数据架构

即租户共享同一个 Database、同一个 Schema，但在表中通过 TenantID 区分租户的数据。
这是共享程度最高、隔离级别最低的模式。
优点：三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原；如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。

7. 分片join

（1）全局表

字典表具有以下几个特性：
• 变动不频繁
• 数据量总体变化不大
• 数据规模不大，很少有超过数十万条记录。

，全局表具有以下特性：
• 全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
• 全局表的查询操作，只从一个节点获取
• 全局表可以跟任何一个表进行 JOIN 操作

（2）ER Join

基于 E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分
片上。customer 采用 sharding-by-intfile 这个分片策略，分片在 dn1,dn2 上，orders 依赖父表进行分片，两个表的关联关系为 orders.customer_id=customer.id。于是数据分片和存储的示意图如下：
分片 Dn1 上的的 customer 与 Dn1 上的 orders 就可以进行局部的 JOIN 联合，Dn2 上也如此，再合并两个节点的数据即可完成整体的 JOIN。

（3）Share join

ShareJoin 是一个简单的跨分片 Join,基于 HBT 的方式实现。目前支持 2 个表的 join,原理就是解析 SQL 语句，拆分成单表的 SQL 语句执行，然后把各个节点的数据汇集。

（4）Spark/Storm Join

mycat 调用 spark,storm的 api,把数据传送到 spark,storm，在 spark,storm 进行 join,在把数据传回 mycat,mycat 在返回给客户端。

8. 全局序列号

全局sequence保证自增主键的全局唯一。

(1)本地文件方式

缺点：当 MyCAT 重新发布后，配置文件中的 sequence 会恢复到初始值。
优点：本地加载，读取速度较快。

(2)数据库方式

在数据库中建立一张表，存放 sequence 名称(name)，sequence 当前值(current_value)，步长(incrementint 类型每次读取多少个 sequence，假设为 K)等信息；

(3) 本地时间戳方式

ID= 64 位二进制 (42(毫秒)+5(机器 ID)+5(业务编码)+12(重复累加)
换算成十进制为 18 位数的 long 类型，每毫秒可以并发 12 位二进制的累加。

(4)分布式 ZK ID 生成器

9. 分片规则

（1）分片枚举 sharding-by-intfile

通过在配置文件中配置可能的枚举 id，自己配置分片固定分片 hash 算法 。

（2）固定分片hash算法func1

类似于十进制的求模运算，区别在于是二进制的操作,是取 id 的二进制低 10 位，即 id 二进制&1111111111。此算法的优点在于如果按照 10 进制取模运算，在连续插入 1-10 时候 1-10 会被分到 1-10 个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度

（3）范围约定 rang-long

提前规划好分片字段某个范围属于哪个分片

（4）取模 mod-long

对分片字段求摸运算。

（5）按日期（天）分片sharding-by-date

（6）取模范围约束 sharding-by-pattern

此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布。

（7）截取数字做 hash 求模范围约束 sharding-by-prefixpattern

此规则支持数据符号字母取模。

（8）应用指定sharding-by-substring

此规则是在运行阶段有应用自主决定路由到那个分片。

（9）截取数字hash 解析sharding-by-stringhash

截取字符串中的 int 数值 hash 分片。

（10）一致性 hash sharding-by-murmur

一致性 hash 预算有效解决了分布式数据的扩容问题。

（11）按单月小时拆分 sharding-by-hour

此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多 24 个分片，最少 1 个分片，一个月完后下月从头开始循环

（12）范围求模分片 auto-sharding-rang-mod

先进行范围分片计算出分片组，组内再求模。优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题。综合了范围分片和求模分片的优点，分片组内使用求模可以保证组内数据比较均匀，分片组之间是范围分片可以兼顾范围查询。最好事先规划好分片的数量，数据扩容时按分片组扩容，则原有分片组的数据不需要迁移。由于分片组内数据比较均匀，所以分片组内可以避免热点数据问题。

（13）日期范围 hash 分片 range-date-hash

思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成 hash 方法。先根据日期分组，再根据时间 hash 使得短期内数据分布的更均匀。优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题。要求日期格式尽量精确些，不然达不到局部均匀的目的

（14）冷热数据分片 sharding-by-hotdate

根据日期查询日志数据 冷热数据分布 ，最近 n 个月的到实时交易库查询，超过 n 个月的按照 m 天分片。

（15）自然月分片 sharding-by-month

按月份列分区 ，每个自然月一个分片

（16）有状态分片算法

（17）crc32slot 分片算法

10.MySQL主从复制方案

（1）主从复制方案

（2）主从复制方式

a.基于SQL语句复制 SBR(statement-based replication)

优点：
• 历史悠久，技术成熟；
• binlog 文件较小；
• binlog 中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况；
• binlog 可以用于实时的还原，而不仅仅用于复制；
• 主从版本可以不一样，从服务器版本可以比主服务器版本高。

缺点：
• 不是所有的 UPDATE 语句都能被复制，尤其是包含不确定操作的时候；
• 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁；
• 对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响；
• 数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错；
• 执行复杂语句如果出错的话，会消耗更多资源。

b.基于行复制 RBR(row-based replication)

优点：
• 任何情况都可以被复制，这对复制来说是最安全可靠的；
• 和其他大多数数据库系统的复制技术一样；
• 多数情况下，从服务器上的表如果有主键的话，复制就会快了很多。

缺点：
• binlog 大了很多；
•复杂的回滚时 binlog 中会包含大量的数据；
•主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会 导致频繁发生binlog 的并发写问题；
•无法从 binlog 中看到都复制了写什么语句。

c.混合模式复制 MBR(mixed-based replication)

（3）MyCat支持的读写分离

MySQL方式读写分离

配置 mysql 端主从的数据自动同步，mycat 不负责任何的数据同步问题。当写节点挂了读不可用。

MyCat方式读写分离

Mycat 配置读写分离，当写节点挂了读可用。事务内部的一切操作都会走写节点，所以读操作不要加事务，如果读延时较大，使用根据主从延时的读写分离，或者强制走写节点。

强制走写：一个查询 SQL 语句以/balance/注解来确定其是走读节点还是写节点。

示例：
强制走从：
/!mycat:db_type=slave/ select * from travelrecord
/#mycat:db_type=slave/ select * from travelrecord
强制走写：
/#mycat:db_type=master/ select * from travelrecord
/!mycat:db_type=master/ select * from travelrecord

根据主从延时切换：
（a）MyCAT 心跳检查语句配置为 show slave status ，dataHost 上定义两个新属性： switchType=“2” 与slaveThreshold=“100”，意味着开启 MySQL 主从复制状态绑定的读写分离与切换机制。
（b）Mycat 心跳机制通过检测 show slave status 中的 “Seconds_Behind_Master”, “Slave_IO_Running”,“Slave_SQL_Running” 三个字段来确定当前主从同步的状态以及 Seconds_Behind_Master 主从复制时延。
（c）当 Seconds_Behind_Master>slaveThreshold 时，读写分离筛选器会过滤掉此 Slave 机器，防止读到很久之前的旧数据。
（d）而当主节点宕机后，切换逻辑会检查 Slave 上的Seconds_Behind_Master 是否为 0，为 0 时则表示主从同步，可以安全切换，否则不会切换。

11. 高可用与集群

（1）MySQL高可用方案

（a）主从复制+读写分离

客户端通过Master对数据库进行写操作，slave端进行读操作，并进行备份。Master出现问题后，可以手动将应用切换到slave端。

应用场景：对数据实时性要求不高。可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈。

（b）MySQL Cluster

应用场景：使用不广泛，安装配置管理复杂。

（c）HeartBeat + 双主复制

heartbeat 是 Linux-HA 工程的一个组件,heartbeat 最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。

（d）HeartBeat + DRBD + MySQL

DRBD 是通过网络来实现块设备的数据镜像同步的一款开源 Cluster 软件，它自动完成网络中两个不同服务器上的磁盘同步，相对于 binlog 日志同步，它是更底层的磁盘同步，理论上 DRDB 适合很多文件型系统的高可用。

（e）Lvs + Keepalived + 双主复制

Lvs 是一个虚拟的服务器集群系统，可以实现 LINUX 平台下的简单负载均衡。keepalived 是一个类似于layer3, 4 & 5 交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方案，最常用于 Web 系统。

（e）MariaDB Galera

这种 gluster 模式可以说是全新的一种高可用方案，前面也提到其优点，它的缺点不多，不支持 XA，不支持Lock Table，只能用 InnoDB 引擎

（2）MyCat高可用方案

（a）MyCat+MySQL主从

Mycat 内部定期对一个 dataHost 里的所有 writeHost 与 readHost 节点发起心跳检测，正常情况下，Mycat 会将第一个 writeHost 作为写节点，所有的 DML SQL 会发送给此节点，若Mycat开启了读写分离，则查询节点会根据读写分离的策略发往readHost(+writeHost)执行，当一个 dataHost 里面配置了两个或多个 writeHost 的情况下，如果第一个 writeHost 宕机，则 Mycat 会在默认的 3 次心跳检查失败后，自动切换到下一个可用的 writeHost 执行 DML SQL 语句，并在 conf/dnindex.properties 文件里记录当前所用的 writeHost 的 index（第一个为 0，第二个为 1，依次类推）

（b）HAproxy + MyCat集群 + MySQL主从

集群部署图的理解：
1、keepalived 和 haproxy 必须装在同一台机器上（如 172.17.210.210.83 机器上，keepalived 和haproxy 都要安装），keepalived 负责为该服务器抢占 vip（虚拟 ip），抢占到 vip 后，对该主机的访问可以通过原来的 ip（172.17.210.210.83）访问，也可以直接通过 vip（172.17.210.210.103）访问。
2、172.17.210.64 上的 keepalived 也会去抢占 vip，抢占 vip 时有优先级，配置keepalived.conf 中的（priority 150 #数值愈大，优先级越高,172.17.210.64 上改为 120，master 和 slave 上该值配置不同）决 定。但是一般哪台主机上的 keepalived 服务先启动就会抢占到 vip，即使是 slave，只要先启动也能抢到。
3、haproxy 负责将对 vip 的请求分发到 mycat 上。起到负载均衡的作用，同时 haproxy 也能检测到 mycat是否存活，haproxy 只会将请求转发到存活的 mycat 上。
4、如果一台服务器（keepalived+haproxy 服务器）宕机，另外一台上的 keepalived 会立刻抢占 vip 并接管服务。
如果一台 mycat 服务器宕机，haporxy 转发时不会转发到宕机的 mycat 上，所以 mycat 依然可用。

12. MyCat管理命令与监控

MyCAT 自身有类似其他数据库的管理监控方式，可以通过 Mysql 命令行，登录管理端口（9066）执行相应的 SQL 进行管理。管理端口是设置在server.xml中。

（1）登录

mysql -h127.0.0.1 –uroot –p123456 –P9066

（2）show @@help;

查看所有的命令。

（3）reload @@config;

用于更新配置文件，不需要进行重启就可以进行文件更新。命令处理时，mycat服务不可用。

（4）show @@database;

显示Mycat数据库的列表。

（5）show @@datanode where schema = ?

查询指定schema下面的dataNode列表。
“NAME”表示 dataNode 的名称；
“DATAHOST”表示对应 dataHost 属性的值，即数据主机；
“ACTIVE”表示活跃连接数；
“IDLE”表示闲置连接数；
“SIZE”对应总连接数量

（6）show @@heartbeat

该命令用于报告心跳状态。
RS_CODE 状态：
OK_STATUS = 1;正常状态
ERROR_STATUS = -1; 连接出错

TIMEOUT_STATUS = -2;连接超时
INIT_STATUS = 0; 初始化状态
若节点故障，会连续默认 5 个周期检测，心跳连续失败，就会变成-1，节点故障确认，然后可能发生切换。

（7）show @@version;

用于获取 MyCAT 的版本。

（8）show @@connection;

用于获取 Mycat 的前端连接状态，即应用与 mycat 的连接。

（9）kill @@connection id,id,id;

用于杀掉连接。

（10）show @@backend;

查看后端连接状态。

（11）show @@cache;

查看mycat缓存。
SQLRouteCache：sql路由缓存。
TableID2DataNodeCache：缓存表主键与分片对应关系。
ER_SQL2PARENTID：缓存 ER 分片中子表与父表关系。

（12）show @@datasource;

查看数据源状态，如果配置了主从，或者多主可以切换。

（13）switch @@datasource name:index

切换数据源。命令处理时，服务不可用。
name：schema中配置的dataHost 中 name。
index：schema 中配置的 dataHost 的 writeHost index 位标，即按照配置顺序从上到下的一次顺序，从 0 开始。
切换数据源时，会将原数据源所有的连接池中连接关闭，并且从新数据源创建新连接，此时 mycat 服务不可用。

（14）show @@syslog limit=?;

用来在客户端命令窗口显示系统日志信息，
通常用于远程查看 Mycat-Server的日志信息
参数：limit=后接正整数，该数值用来限定每次最多显示的日志条数

（15）reload @@user_stat;

用来将客户端执行 show @@sql ; show @@sql.sum ; show @@slow.success ;命令之后所缓存的信息清空；

（16）show @@sql;

用来记录用户通过本地 8066 端口向 Mycat-Server 发送的 SQL 请求执行信息包括有 ID 值，执行 SQL 语句的用户名称，执行的 SQL 语句，命令执行的起始时间，命令执行消耗时间。

（17）show @@sql.slow ;

是用来将用户通过 8066 端口向 Mycat-Server 发送的请求执行 SQL 语句中超过慢 SQL 时间阈值的SQL 语句信息。在这里首先应该明确的是何为’慢 SQL，所谓的慢 SQL 是执行时间相对时间阈值耗时较长的 SQL 语句。

（18）reload @@sqlslow=0 ;

设定慢 SQL时间阈值。

（19）show @@sql.sum ;

是用来向用户展示本地 8066 号端口上执行的 SQL 命令的统计信息数据。其中 R,W 分别记录的是当前用户 (USER:test) 在 8066 端口的命令窗口中执行的 SQL 语句中，有多少条读取数据库信息的语句，有多少条执行写操作的语句，R%是读写操作中读操作所占百分比；

13.压缩协议

Mycat从 1.4开始支持mysql的压缩协议，在查询返回大的结果集和 load data 大量数据的性能提升比较明显。可以大大节省网络流量，但会消耗少量cpu资源。

Mycat 可以在 server.xml 中配置启用。如下图：

客户端如果是 mysql 命令行，则加参数-C 启用压缩协议。
客户端如果是 jdbc 则在 jdbc 的 url 上加上参数 useCompression=true，例如：
jdbc:mysql://127.0.0.1:8066/base?useCompression=true

14.MyCat-Web

（1）MyCat-Web下载

下载地址：http://dl.mycat.org.cn/mycat-web-1.0/
解压：tar –xvf http://dl.mycat.org.cn/mycat-web-1.0/Mycat-web-1.0-SNAPSHOT-20170102153329-linux.tar.gz

（2）修改端口

MyCat-Web的默认端口是8082，如果端口有冲突，可以修改端口。
文件路径是：mycat安装目录下的etc文件夹的jetty.xml。

（3）启动MyCat-Web

在启动MyCat-Web之前需要启动ZooKeeper，MyCat-Web的使用需要ZooKeeper作为注册中心。

（a）启动ZooKeeper

命令：bin/zkServer.sh start

查看zookeeper日志文件：

（b）启动MyCat-Web

命令 ./start.sh &
注意&是以后台进程的形式启动，即使关闭控制台，也不会有影响。

（4）登录MyCat-Web

登录地址：http://193.112.47.238:8882/mycat

遇到问题：MyCat配置管理–>新增MyCat，提交一直在Loading，我使用的版本是1.6.6.1，网上的说法是MyCat1.6.6.1不支持Web。

15. HAProxy安装

（1）下载地址

wget http://download.openpkg.org/components/cache/haproxy/haproxy-2.2.3.tar.gz

（2）解压

tar zxvf haproxy-2.2.3.tar.gz

（3）进入解压目录

cd haproxy-2.2.3/

（4）安装

//这里需要使用uname -r查看系统版本
//centos6.X需要使用TARGET=linux26 centos7.x使用linux31
make TARGET=linux31
make install PREFIX=/usr/local/haproxy
mkdir /usr/local/haproxy/conf
cp examples/option-http_proxy.cfg /usr/local/haproxy/conf/haproxy.cfg

（5）启动

/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

16. MyCat缺点

（1）除了分片规则相同、ER 分片、全局表、以及 SharedJoin，其他表之间的 Join 问题目前还没有很好的解决，需要自己编写 Catlet 来处理。
（2）不支持 Insert into 中不包括字段名的 SQL。
（3）insert into x select from y 的 SQL，若 x 与 y 不是相同的分片规则，则不被支持，此时会涉及到跨分片转移。
（4）跨分片的事务，目前只是弱 XA 模式，还没完全实现 XA 模式。
（5）分片的 Table，目前不能执行 Lock Table 这样的语句，因为这种语句会随机发到某个节点，也不会全部分片锁定，经常导致死锁问题，此类问题常常出现在 sqldump 导入导出 SQL 数据的过程中。
（6）目前 sql 解析器采用 Druid，在某些 sql 例如 order，group，sum ，count 条件下，这类操作会出现兼容问题，比如：
select t.name as name1 from test order by t.name
这条语句 select 列的别名与 order by 不一致解析器会出现异常，所以在对列加别名时候要注意这类操作异常，特别是由 jpa 等类似的框架生成的语句会有兼容问题。
（7）开发框架方面，虽然支持 Hibernate，但不建议使用 Hibernate，而是建议 Mybatis 以及直接 JDBC 操作，原因 Hibernat 无法控制 SQL 的生成，无法做到对查询 SQL 的优化，导致大数量下的性能问题。
（8）事务方面，建议自己手动控制，查询语句尽量走自动提交事务模式，这样 Mycat 的读写分离会被用到，提升性能很明显。

17. MyCat与Cobar比较

（1）MyCat比Cobar减少了线程切换

Cobar 的线程模型中存在着大量的上下文切换,MyCAT 的线程调度尽量减少了线程间的切换，以写为例：Cobar 是业务线程先把写请求交给专门的 W 线程，W 线程再写过程中发现通道繁忙时再交给 R 线程；MyCAT 对写的做法是业务线程发现通道空闲直接写，只有在通道繁忙时再交给 Reactor 线程。

（2）减少线程切换与业务可能停顿的矛盾

对业务逻辑进行归类：

• 对于业务较重的，比如大结果集排序，则送到 BusinessExecutor 线程池进行下一步处理；
• 对于业务较轻的，比如单库直接转发的情况，则由 Reactor 直接完成，不再送线程池，减少上下文切换。

18. MyCat的NIO和AIO

MyCat同时支持NIO和AIO。

（1） NIO 非堵塞同步

NIO对应的设计模式是Reactor。在 Reactor 模式中，事件分离者等待某个事件或者应用或操作的状态发生（比如文件描述符可读写，或者是 socket 可读写）,事件分离者就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。
下面是 Reactor 的做法：

1. 等待事件响应 (Reactor job)。
2. 分发 “Ready-to-Read” 事件给用户句柄 ( Reactor job)。
3. 读数据 (user handler job)。
4. 处理数据( user handler job)。

（2） AIO 非堵塞异步

AIO对应的设计模式是Proactor。在 Proactor 模式中，事件处理者(或者代由事件分离者发起)直接发起一个异步读写操作(相当于请求)，而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区，读的数据大小，或者用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分离者得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。
下面是 Proactor的做法：

1. 等待事件响应 (Reactor job)。
2. 读数据 (user handler job)。
3. 分发 “Read-Completed” 事件给用户句柄 ( Reactor job)。
4. 处理数据( user handler job)。

（3）Reactor和Proactor的区别

Reactor 和 Proactor 模式的主要区别就是真正的读取和写入操作是有谁来完成的：
A． Reactor 中需要应用程序自己读取或者写入数据，
B． Proactor 模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的 IO 设备。

19. 路由计算

20. MyCat缓存

（1） SQLRouteCache(SQL语句路由缓存)

路由缓存，通过缓存 SQL 语句的路由信息，下次查询，不用再进行路由计算了，直接从缓存中获取路由信息，然后发到各个节点执行。

（2） TableID2DataNodeCache(表主键节点缓存)

表主键 ID 的路由缓存，为每一个表建一个缓存池，命名为 TableID2DataNodeCache.TESTDB_表名,缓存的key 是 id 的值，value 是节点名。

（3）ER_SQL2PARENTID(ER 关系缓存)

ER 关系的缓存目前只是在 Insert 语句中才会使用缓存，子表插入数据的时候，根据 joinKey 的值，判断父表所在分片，从而定位子表分片，分片信息 put 缓存，以便下次直接获取