MySQL分库分表
为什么要分库分表
==================为什么要分库
如果业务量剧增，数据库可能会出现性能瓶颈，这时候我们就需要考虑拆分数据库。从这两方面来看：
1）磁盘存储
业务量剧增，MySQL单机磁盘容量会撑爆，拆成多个数据库，磁盘使用率大大降低。
2）并发连接支撑
我们知道数据库连接数是有限的。在高并发的场景下，大量请求访问数据库，MySQL单机是扛不住的。高并发场景下，会出现too many connections报错。当前非常火的微服务架构出现，就是为了应对高并发。它把订单、用户、商品等不同模块，拆分成多个应用，并且把单个数据库也拆分成多个不同功能模块的数据库（订单库、用户库、商品库），以分担读写压力。
==================为什么要分表
假如你的单表数据量非常大，存储和查询的性能就会遇到瓶颈了，如果你做了很多优化之后还是无法提升效率的时候，就需要考虑做分表了。一般千万级别数据量，就需要分表。这是因为即使SQL命中了索引，如果表的数据量超过一千万的话，查询也是会明显变慢的。这是因为索引一般是B+树结构，数据千万级别的话，B+树的高度会增高，查询就变慢啦。
==================什么时候考虑分库分表
对于MySQL，InnoDB存储引擎的话，单表最多可以存储10亿级数据。但是的话，如果真的存储这么多，性能就会非常差。一般数据量千万级别，B+树索引高度就会到3层以上了，查询的时候会多查磁盘的次数，SQL就会变慢。
阿里巴巴的《Java开发手册》提出：
单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
那我们是不是等到数据量到达五百万，才开始分库分表呢？
不是这样的，我们应该提前规划分库分表，如果估算3年后，你的表都不会到达这个五百万，则不需要分库分表。
MySQL服务器如果配置更好，是不是可以超过这个500万这个量级，才考虑分库分表？
虽然配置更好，可能数据量大之后，性能还是不错，但是如果持续发展的话，还是要考虑分库分表。
一般什么类型业务表需要才分库分表？
通用是一些流水表（订单、报文等）、用户表等才考虑分库分表，如果是一些配置类的表，则完全不用考虑，因为不太可能到达这个量级。
分库分表策略
分库方式与数量选择
当数据量达到一定程度时，我们出于性能考虑就需要将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。数据的切分同一时候还能够提高系统的总体可用性，由于单台设备Crash之后。仅仅有总体数据的某部分不可用，而不是全部的数据。数据的切分（Sharding）依据其切分规则的类型，能够分为垂直切分、水平切分、联合切分模式。
1）分库分表方式
根据数值范围，比如用户Id为1-9999的记录分到第一个库，10000-20000的分到第二个库，以此类推。根据数值取模，比如用户Id mod n，余数为0的记录放到第一个库，余数为1的放到第二个库，以此类推。mod分库一般每个库记录数比较均匀，但也有些数据库，存在超级Id（这些Id的记录远远超过其他Id）。如果按照该Id取模分库，某些库的记录数会特别多，对于这些超级Id，需要提供单独库来存储记录。
2）分库数量
分库数量首先和单库能处理的记录数有关，一般来说，Mysql单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大（当然处理能力和字段数量、访问模式、记录长度有进一步关系）。在满足上述前提下，如果分库数量少，达不到分散存储和减轻DB性能压力的目的；如果分库的数量多，好处是每个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序需要访问多个库，如果是并发模式，要消耗宝贵的线程资源；如果是串行模式，执行时间会急剧增加。最后分库数量还直接影响硬件的投入，一般每个分库跑在单独物理机上，多一个库意味多一台设备。所以具体分多少个库，要综合评估，一般初次分库建议分4-8个库。
根据业务纵向分库
根据业务耦合性，将关联度低的不同表存储在不同的数据库，做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与微服务治理的做法相似，每个微服务使用单独的一个数据库。
根据字段垂直分表
基于数据库中的列进行，某个表字段较多，可以新建一张扩展表，将不经常用或者字段长度较大的字段拆出到扩展表中。在字段很多的情况下，通过大表拆小表，更便于开发与维护，也能避免跨页问题，MySql底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的开销。另外，数据库以行为单位将数据加载到内存中，这样表中字段长度越短且访问频次较高，内存能加载更多的数据，命中率更高，减少磁盘IO，从而提升数据库的性能。垂直切分的优点和缺点：
优点：
1、解决业务系统层面的耦合，业务清晰
2、与微服务的治理类似，也能对不同业务的数据进行分级管理，维护，监控，扩展等
3、高并发场景下，垂直切分一定程度的提升IO，数据库连接数，单机硬件资源的瓶颈
缺点：
1、部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
2、分布式事务处理复杂
3、依然存在单表数据量过大的问题
根据数据量水平分表
当一个应用难以再细粒度的垂直切分或切分后数据量行数依然巨大，存在单库读写，存储性能瓶颈，这时候需要进行水平切分。可分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。库内分表只解决单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySql的压力来说帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。水平切分优点和缺点：
优点：
1、不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
2、应用端改造较小，不需要拆分业务模块
缺点：
1、跨分片的事务一致性难以保证
2、跨库的join关联查询性能较差
3、数据多次扩展维度和维护量极大
分库分表数据整合方案
数据库中的数据在经过垂直或水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合。
方案一：可以在每一个应用程序模块中配置管理自己须要的一个（或者多个）数据源。直接访问各个数据库，在模块内完成数据的整合。
方案二：通过中间代理层来统一管理全部的数据源，后端数据库集群对前端应用程序透明。可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候，尽管短期内须要付出的成本可能会相对更大一些，可是对整个系统的扩展性来说，是非常有帮助的。
具体实施方案：
1）自行开发中间代理层
2）利用MySQLProxy实现数据切分及整合
3）利用Amoeba实现数据切分及整合
3）利用HiveDB实现数据切分及整合
4）利用mycat进行数据整合 资料：http://www.songwie.com/articlelist/11
5）其他整合方式，如ShardingJDBC
如何选择分表键
分表键，即用来分库分表的字段，换种说法就是，你以哪个维度来分库分表的。比如你按用户ID分表、按时间分表、按地区分表，这些用户ID、时间、地区就是分表键。一般数据库表拆分的原则，需要先找到业务的主题。比如你的数据库表是一张企业客户信息表，就可以考虑用了客户号做为分表键。这是因为表是基于客户信息的，所以，需要将同一个客户信息的数据，落到一个表中，避免触发全表路由。
非分表键如何查询
分库分表后，有时候无法避免一些业务场景，需要通过非分表键来查询。假设一张用户表，根据userId做分表键，来分库分表。但是用户登录时，需要根据用户手机号来登陆。这时候，就需要通过手机号查询用户信息。而手机号是非分表键。非分表键查询，一般有这几种方案：
1）遍历：最粗暴的方法，就是遍历所有的表，找出符合条件的手机号记录（不建议）
2）将用户信息冗余同步到ES，同步发送到ES，然后通过ES来查询（推荐）
3）其实还有基因法：比如非分表键可以解析出分表键出来，比如常见的，订单号生成时，可以包含客户号进去，通过订单号查询，就可以解析出客户号。但是这个场景除外，手机号似乎不适合冗余userId。
分表策略如何选择
1）range范围策略
range，即范围策略划分表。比如我们可以将表的主键order_id，按照从0~300万的划分为一个表，300万~600万划分到另外一个表。有时候我们也可以按时间范围来划分，如不同年月的订单放到不同的表，它也是一种range的划分策略。
优点：Range范围分表，有利于扩容。
缺点：可能会有热点问题。因为订单id是一直在增大的，也就是说最近一段时间都是汇聚在一张表里面的。比如最近一个月的订单都在300万~600万之间，平时用户一般都查最近一个月的订单比较多，请求都打到order_1表啦。
2）hash取模策略
指定的路由key（一般是user_id、order_id、customer_no作为key）对分表总数进行取模，把数据分散到各个表中。比如id=1，对4取模，就会得到1，就把它放到t_order_1。id=3，对4取模，就会得到3，就把它放到t_order_3。一般，我们会取哈希值，再做取余：
Math.abs(orderId.hashCode()) % table_number
优点：hash取模的方式，不会存在明显的热点问题。
缺点：如果未来某个时候，表数据量又到瓶颈了，需要扩容，就比较麻烦。所以一般建议提前规划好，一次性分够。（可以考虑一致性哈希）
3）一致性Hash策略
如果用hash方式分表，前期规划不好，需要扩容二次分表，表的数量需要增加，所以hash值需要重新计算，这时候需要迁移数据了。比如我们开始分了10张表，之后业务扩展需要，增加到20张表。那问题就来了，之前根据orderId取模10后的数据分散在了各个表中，现在需要重新对所有数据重新取模20来分配数据。为了解决这个扩容迁移问题，可以使用一致性hash思想来解决。
一致性哈希：在移除或者添加一个服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表存在的动态伸缩等问题。
不停服的情况下分表
1）编写代理层，加个开关（控制访问新的DAO还是老的DAO，或者是都访问），灰度期间，还是访问老的DAO。
2）发版全量后，开启双写，既在旧表新增和修改，也在新表新增和修改。日志或者临时表记下新表ID起始值，旧表中小于这个值的数据就是存量数据，这批数据就是要迁移的。
3）通过脚本把旧表的存量数据写入新表。
4）停读旧表改读新表，此时新表已经承载了所有读写业务，但是这时候不要立刻停写旧表，需要保持双写一段时间。
5）当读写新表一段时间之后，如果没有业务问题，就可以停写旧表啦
分库分表引发的问题思考
分表后数据倾斜
问题说明：如果我们根据时间范围分片，某电商公司11月搞营销活动，那么大部分的数据都落在11月份的表里面了，其他分片表可能很少被查询，即数据倾斜，有热点数据问题了。
解决方案：我们可以使用range范围+hash哈希取模结合的分表策略，简单的做法就是：在拆分库的时候，我们可以先用range范围方案，比如订单id在0~4000万的区间，划分为订单库1，id在4000万~8000万的数据，划分到订单库2，将来要扩容时，id在8000万~1.2亿的数据，划分到订单库3。然后订单库内，再用hash取模的策略，把不同订单划分到不同的表。
跨节点事务问题
方案一：使用分布式事务
优点：交由数据库管理，简单有效
缺点：性能代价高，特别是shard越来越多时
方案二：由应用程序和数据库共同控制
原理：将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。
优点：性能上有优势
缺点：需要应用程序在事务控制上做灵活设计。如果使用了spring的事务管理，改动起来会面临一定的困难。
跨节点Join问题
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id，根据这些id发起第二次请求得到关联数据。
跨库Join的几种解决思路：
1）字段冗余：把需要关联的字段放入主表中，避免关联操作；比如订单表保存了卖家ID（sellerId），你把卖家名字sellerName也保存到订单表，这就不用去关联卖家表了。这是一种空间换时间的思想。
2）全局表：比如系统中所有模块都可能会依赖到的一些基础表（即全局表），在每个数据库中均保存一份。
3）数据抽象同步：比如A库中的a表和B库中的b表有关联，可以定时将指定的表做同步，将数据汇合聚集，生成新的表。一般可以借助ETL工具。
4）应用层代码组装：分开多次查询，调用不同模块服务，获取到数据后，代码层进行字段计算拼装。
跨节点函数问题
跨节点的count,order by,group by以及聚合函数等问题，都是一类的问题，它们一般都需要基于全部数据集合进行计算。可以分别在各个节点上得到结果后，再在应用程序端进行合并。多数的代理都不会自动处理合并工作。
解决方案：与解决跨节点Join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和Join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
跨节点ID唯一性
在分布式系统中，需要生成全局ID的场合还是比较多的，twitter的snowflake（雪花算法）解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位、机器ID10位、毫秒内序列12位。经测试，snowflake每秒能够产生26万ID左右，完全满足需要。
跨节点分页问题
如果是在前台应用提供分页，则限定用户只能看前面n页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。
如果是后台批处理任务要求分批获取数据，则可以加大page size，比如每次获取5000条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。
分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。
方案1（全局视野法）：在各个数据库节点查到对应结果后，在代码端汇聚再分页。这样优点是业务无损，精准返回所需数据；缺点则是会返回过多数据，增大网络传输，也会造成空查，比如分库分表前，你是根据创建时间排序，然后获取第2页数据。如果你是分了两个库，那你就可以每个库都根据时间排序，然后都返回2页数据，然后把两个数据库查询回来的数据汇总，再根据创建时间进行内存排序，最后再取第2页的数据。
方案2（业务折衷法-禁止跳页查询）：这种方案需要业务妥协一下，只有上一页和下一页，不允许跳页查询了。这种方案，查询第一页时，是跟全局视野法一样的。但是下一页时，需要把当前最大的创建时间传过来，然后每个节点，都查询大于创建时间的一页数据，接着汇总，内存排序返回。
跨节点数据迁移、容量规划、扩容等
来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
分库分表中间件
多种中间件选择
MyCat中间件简介
MyCat是一个开源的分布式数据库系统，前端用户可以把它看作是一个数据库代理。其实现的核心原理是拦截。MyCat拦截用户发送过来的Sql语句，做一些特定的分析：如分片分析，路由分析，读写分析，读写分离分析。然后将SQL发往真实的数据库。不同于其他的中间件比如Druid连接池，MyCat使用的是NIO异步通信机制（非阻塞型的），它的线程池数量默认为1，实际生产环境线程数等于CPU的核数。在日常的工作中，关系型数据库本身比较容易成为系统的瓶颈点，虽然读写分离能分散数据库的读写压力，但并没有分散存储压力，当数据量达到千万甚至上亿时，单台数据库服务器的存储能力会成为系统的瓶颈，主要体现在以下几个方面：
1、数据量太大，读写的性能会下降，即使有索引，索引也会变得很大，性能同样会降下。
2、数据库文件会得很大，数据库备份和恢复需要耗时很长。
3、数据库文件越大，极端情况下丢失数据的风险越高。
因此，当流量越来越大时，且单机容量达到上限时，此时需要考虑对其进行切分，切分的目的就在于减少单机数据库的负担，将由多台数据库服务器一起来分担，缩短查询时间。MyCat应用主要有下面这些场景：
1）单纯的读写分离，此时配置最为简单，支持读写分离，主从切换。
2）分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片。
3）多租户应用，每个应用一个库，但应用程序只连接MyCat，从而不改造程序本身，实现多租户化。
4）报表系统，借助于MyCat的分表能力，处理大规模报表的统计，替代Hbase，分析大数据。
5）作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时MyCat可能是最简单有效的选择。
MyCat主要配置有：
schema.xml：MyCat对应的物理数据库和数据库表的配置
rule.xml：里面就定义了我们对表进行拆分所涉及到的规则定义。我们可以灵活的对表使用不同的分片算法，或者对表使用相同的算法但具体的参数不同。包含的标签tableRule和function。
server.xml：MyCat的配置文件，设置账号、参数等
wrapper.conf：配置jdk所在路径
MyCat配置之schema.xml
<?xml version="1.0"?>
<!DOCTYPE MyCat:schema SYSTEM "schema.dtd">
<MyCat:schema xmlns:MyCat="http://io.MyCat/">
<!-- schema：数据库设置，此数据库为逻辑数据库，name与server.xml中schema对应 -->
<!-- schema标签用来定义MyCat实例中的逻辑库，MyCat可以有多个逻辑库，每个逻辑库都有自己的相关配置。可以使用schema标签来划分这些不同的逻辑库，如果不配置schema标签，所有表的配置会属于同一个默认的逻辑库。逻辑库的概念和MySql的database的概念一样，我们在查询两个不同逻辑库中的表的时候，需要切换到该逻辑库下进行查询。 -->
<!-- name：逻辑数据库名，与server.xml中的schema对应。
checkSQLschema：数据库前缀相关设置，当该值为true时，例如我们执行语句select * from TESTDB.company。MyCat会把语句修改为 select * from company 去掉TESTDB。
sqlMaxLimit：当该值设置为某个数值时，每条执行的sql语句，如果没有加上limit语句，MyCat会自动加上对应的值。不写的话，默认返回所有的值。需要注意的是，如果运行的schema为非拆分库的，那么该属性不会生效。需要自己sql语句加limit。 -->
<schema name="TESTDB" checkSQLschema="true" sqlMaxLimit="100" randomDataNode="dn1">
<!-- table：表示在MyCat中的逻辑表配置，逻辑表名称为:travelrecord,address，映射到3个数据库节点dataNode中，切分规则为:rule1(在rule.xml配置) -->
<!-- name：表名，物理数据库中表名。
dataNode：表存储到哪些节点，多个节点用逗号分隔，节点为下文dataNode设置的name。
primaryKey：主键字段名，自动生成主键时需要设置。
autoIncrement：是否自增。
rule：分片规则名，具体规则下文rule详细介绍。
type：该属性定义了逻辑表的类型，目前逻辑表只有全局表和普通表。全局表：global，普通表：无。注：全局表查询任意节点，普通表查询所有节点效率低。
splitTableNames：启用name属性使用逗号分割配置多个表，即多个表使用这个配置。
needAddLimit：指定表是否需要自动的在每个语句后面加上limit限制，由于使用了分库分表，数据量有时候会特别庞大，这时候执行查询语句，忘记加上limt就会等好久，所以MyCat自动为我们加上了limit 100，这个属性默认为true，可以自己设置为false禁用。如果使用这个功能，最好配合使用数据库模式的全局序列。
subTables：分表，分表目前不支持Join。-->
<table name="travelrecord,address" dataNode="dn1,dn2,dn3" rule="auto-sharding-long" splitTableNames ="true"/>
<table name="company" primaryKey="ID" type="global" dataNode="dn1,dn2,dn3" />
<table name="customer" primaryKey="ID" dataNode="dn1,dn2" rule="sharding-by-intfile">
<!-- childTable：标签用于定义E-R分片的子表。通过标签上的属性与父表进行关联。
name：子表的名称。
joinKey：子表中字段的名称。
parentKey：父表中字段名称。
primaryKey：同Table。
needAddLimit：同Table。 -->
<childTable name="c_a" primaryKey="ID" joinKey="customer_id" parentKey="id" />
</table>
</schema>
<!-- dataNode：分片信息，也就是分库相关配置 -->
<!-- datanode标签定义了MyCat中的数据节点，也就是我们所说的数据分片。一个datanode标签就是一个独立的数据分片。例子中的表述的意思为，使用名字为localhost1数据库实例上的db1物理数据库，这就组成一个数据分片，最后我们用dn1来标示这个分片。 -->
<!-- name：定义数据节点的名字，这个名字需要唯一，我们在table标签上用这个名字来建立表与分片对应的关系。
dataHost：用于定义该分片属于哪个数据库实例，属性与datahost标签上定义的name对应。
database：用于定义该分片属于数据库实例上的具体库。 -->
<dataNode name="dn1" dataHost="localhost1" database="db1" />
<dataNode name="dn2" dataHost="localhost1" database="db2" />
<dataNode name="dn3" dataHost="localhost1" database="db3" />
<!-- dataHost：物理数据库，真正存储数据的数据库 -->
<!-- 这个标签直接定义了具体数据库实例，读写分离配置和心跳语句 -->
<!-- name：唯一标示dataHost标签，供上层使用。
maxCon：指定每个读写实例连接池的最大连接。
minCon：指定每个读写实例连接池的最小连接，初始化连接池的大小。
balance：负载均衡类型。
--balance="0"：不开启读写分离机制，所有读操作都发送到当前可用的writeHost上。
--balance="1"：全部的readHost与stand by writeHost参与select语句的负载均衡，简单的说，当双主双从模式（M1-S1，M2-S2 并且M1 M2互为主备），正常情况下，M2,S1,S2都参与select语句的负载均衡。
--balance="2"：所有读操作都随机的在writeHost、readHost上分发。
--balance="3"：所有读请求随机的分发到writeHst对应的readHost执行，writeHost不负担读写压力。（1.4之后版本有）
writeType：负载均衡类型。
--writeType="0", 所有写操作发送到配置的第一个 writeHost，第一个挂了切到还生存的第二个writeHost，重新启动后已切换后的为准，切换记录在配置文件中:dnindex.properties。
--writeType="1"，所有写操作都随机的发送到配置的 writeHost。1.5以后版本废弃不推荐。
switchType：
-1 不自动切换
1 默认值 自动切换
2 基于MySql主从同步的状态决定是否切换心跳语句为 show slave status
3 基于mysql galary cluster 的切换机制（适合集群）1.4.1 心跳语句为 show status like 'wsrep%'
dbType：指定后端链接的数据库类型目前支持二进制的mysql协议，还有其他使用jdbc链接的数据库，例如：mongodb，oracle，spark等。
dbDriver：指定连接后段数据库使用的driver，目前可选的值有native和JDBC。使用native的话，因为这个值执行的是二进制的mysql协议，所以可以使用mysql和maridb，其他类型的则需要使用JDBC驱动来支持。如果使用JDBC的话需要符合JDBC4标准的驱动jar放到MyCat\lib目录下，并检查驱动jar包中包括如下目录结构文件META-INF\services\java.sql.Driver。在这个文件写上具体的driver类名，例如com.mysql.jdbc.Driver
writeHost readHost指定后端数据库的相关配置给MyCat，用于实例化后端连接池。
tempReadHostAvailable：如果配置了这个属性，writeHost下面的readHost仍旧可用，默认0，可配置（0、1）。 -->
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="0"
writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
<!-- heartbeat：这个标签内指明用于和后端数据库进行心跳检查的语句。
例如：MYSQL 可以使用 select user()，Oracle 可以使用 select 1 from dual 等。 -->
<heartbeat>select user()</heartbeat>
<!-- writeHost/readHost：这两个标签都指定后端数据库的相关配置，用于实例化后端连接池。唯一不同的是，writeHost 指定写实例、readHost 指定读实例。
在一个 dataHost 内可以定义多个 writeHost 和 readHost。但是，如果 writeHost 指定的后端数据库宕机，那么这个 writeHost 绑定的所有 readHost 都将不可用。
另一方面，由于这个 writeHost 宕机，系统会自动的检测到，并切换到备用的 writeHost 上去。这两个标签的属性相同，这里就一起介绍。 -->
<!-- host：用于标识不同实例，一般 writeHost 我们使用*M1，readHost 我们用*S1。
url：后端实例连接地址吗，Native：地址：端口，JDBC：jdbc的url。
password：后端存储实例需要的密码。
user：后端存储实例需要的用户名字
weight：权重，配置在 readhost 中作为读节点的权重。
usingDecrypt：是否对密码加密，默认0。具体加密方法看官方文档。 -->
<writeHost host="hostM1" url="localhost:3306" user="root"
password="123456">
</writeHost>
</dataHost>
</MyCat:schema>
MyCat配置之rule.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE MyCat:rule SYSTEM "rule.dtd">
<MyCat:rule xmlns:MyCat="http://io.MyCat/">
<!-- tableRule：定义的表规则 -->
<!-- name：属性指定唯一的名字，用于标识不同的表规则。内嵌的rule标签则指定对物理表中的哪一列进行拆分和使用什么路由算法。
columns：指定要拆分的列名字。
algorithm：使用function标签中的name属性。连接表规则和具体路由算法。当然，多个表规则可以连接到同一个路由算法上。table标签内使用。让逻辑表使用这个规则进行分片。 -->
<tableRule name="rule1">
<rule>
<columns>id</columns>
<algorithm>func1</algorithm>
</rule>
</tableRule>
<tableRule name="sharding-by-date">
<rule>
<columns>createTime</columns>
<algorithm>partbyday</algorithm>
</rule>
</tableRule>
<tableRule name="rule2">
<rule>
<columns>user_id</columns>
<algorithm>func1</algorithm>
</rule>
</tableRule>
<tableRule name="sharding-by-intfile">
<rule>
<columns>sharding_id</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<tableRule name="auto-sharding-long">
<rule>
<columns>id</columns>
<algorithm>rang-long</algorithm>
</rule>
</tableRule>
<tableRule name="mod-long">
<rule>
<columns>id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<tableRule name="sharding-by-murmur">
<rule>
<columns>id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
<tableRule name="crc32slot">
<rule>
<columns>id</columns>
<algorithm>crc32slot</algorithm>
</rule>
</tableRule>
<tableRule name="sharding-by-month">
<rule>
<columns>create_time</columns>
<algorithm>partbymonth</algorithm>
</rule>
</tableRule>
<tableRule name="latest-month-calldate">
<rule>
<columns>calldate</columns>
<algorithm>latestMonth</algorithm>
</rule>
</tableRule>
<tableRule name="auto-sharding-rang-mod">
<rule>
<columns>id</columns>
<algorithm>rang-mod</algorithm>
</rule>
</tableRule>
<tableRule name="jch">
<rule>
<columns>id</columns>
<algorithm>jump-consistent-hash</algorithm>
</rule>
</tableRule>
<!-- name：指定算法的名字。
class：制定路由算法具体的类名字。
property：为具体算法需要用到的一些属性。 -->
<function name="murmur"
class="io.MyCat.route.function.PartitionByMurmurHash">
<property name="seed">0</property><!-- 默认是0 -->
<property name="count">2</property><!-- 要分片的数据库节点数量，必须指定，否则没法分片 -->
<property name="virtualBucketTimes">160</property><!-- 一个实际的数据库节点被映射为这么多虚拟节点，默认是160倍，也就是虚拟节点数是物理节点数的160倍 -->
<!-- <property name="weightMapFile">weightMapFile</property> 节点的权重，没有指定权重的节点默认是1。以properties文件的格式填写，以从0开始到count-1的整数值也就是节点索引为key，以节点权重值为值。所有权重值必须是正整数，否则以1代替 -->
<!-- <property name="bucketMapPath">/etc/MyCat/bucketMapPath</property>
用于测试时观察各物理节点与虚拟节点的分布情况，如果指定了这个属性，会把虚拟节点的murmur hash值与物理节点的映射按行输出到这个文件，没有默认值，如果不指定，就不会输出任何东西 -->
</function>
<function name="crc32slot"
class="io.MyCat.route.function.PartitionByCRC32PreSlot">
<property name="count">2</property><!-- 要分片的数据库节点数量，必须指定，否则没法分片 -->
</function>
<function name="hash-int"
class="io.MyCat.route.function.PartitionByFileMap">
<property name="mapFile">partition-hash-int.txt</property>
</function>
<function name="rang-long"
class="io.MyCat.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
</function>
<function name="mod-long" class="io.MyCat.route.function.PartitionByMod">
<!-- how many data nodes -->
<property name="count">3</property>
</function>
<function name="func1" class="io.MyCat.route.function.PartitionByLong">
<property name="partitionCount">8</property>
<property name="partitionLength">128</property>
</function>
<function name="latestMonth"
class="io.MyCat.route.function.LatestMonthPartion">
<property name="splitOneDay">24</property>
</function>
<function name="partbymonth"
class="io.MyCat.route.function.PartitionByMonth">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2015-01-01</property>
</function>
<function name="partbyday"
class="io.MyCat.route.function.PartitionByDate">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sNaturalDay">0</property>
<property name="sBeginDate">2014-01-01</property>
<property name="sEndDate">2014-01-31</property>
<property name="sPartionDay">10</property>
</function>
<function name="rang-mod" class="io.MyCat.route.function.PartitionByRangeMod">
<property name="mapFile">partition-range-mod.txt</property>
</function>
<function name="jump-consistent-hash" class="io.MyCat.route.function.PartitionByJumpConsistentHash">
<property name="totalBuckets">3</property>
</function>
</MyCat:rule>
MyCat配置之server.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE MyCat:server SYSTEM "server.dtd">
<MyCat:server xmlns:MyCat="http://io.MyCat/">
<!-- system：这个标签内嵌套的所有，property：标签都与系统配置有关。 -->
<!-- system标签下的属性，一般是上线后，需要根据实际运行的情况，分析后调优的时候进行修改。 -->
<system>
<!-- 字符集 -->
<property name="charset">utf8</property>
<!-- 0为需要密码登陆、1为不需要密码登陆，默认为0，设置为1则需要指定默认账户 -->
<property name="nonePasswordLogin">0</property>
<!-- 0遇上没有实现的报文(Unknown command:)，就会报错、1为忽略该报文，返回ok报文。
在某些mysql客户端存在客户端已经登录的时候还会继续发送登录报文，MyCat会报错，该设置可以绕过这个错误 -->
<property name="ignoreUnknownCommand">0</property>
<property name="useHandshakeV10">1</property>
<property name="removeGraveAccent">1</property>
<!-- 是否开启实时统计。1为开启；0为关闭 。 -->
<property name="useSqlStat">0</property>
<!-- 是否开启全局表一致性检测。1为开启；0为关闭 。 -->
<property name="useGlobleTableCheck">0</property>
<!-- SQL执行超时的时间，MyCat会检查连接上最后一次执行SQL的时间，若超过这个时间则会直接关闭这连接。默认时间为300秒，单位秒 -->
<property name="sqlExecuteTimeout">300</property>
<property name="sequnceHandlerType">1</property>
<!-- INSERT INTO `travelrecord` (`id`,user_id) VALUES ('next value for MyCatSEQ_GLOBAL',"xxx"); -->
<property name="sequnceHandlerPattern">(?:(\s*next\s+value\s+for\s*MyCatSEQ_(\w+))(,|\)|\s)*)+</property>
<!-- 必须带有MyCatSEQ_或者MyCatseq_进入序列匹配流程，注意MyCatSEQ_有空格的情况 -->
<property name="sequnceHandlerPattern">(?:(\s*next\s+value\s+for\s*MyCatSEQ_(\w+))(,|\)|\s)*)+</property>
<!-- 子查询中存在关联查询的情况下，检查关联字段中是否有分片字段，默认false -->
<property name="subqueryRelationshipCheck">false</property>
<property name="sequenceHanlderClass">io.MyCat.route.sequence.handler.HttpIncrSequenceHandler</property>
<!-- 是否开启mysql压缩协议。1为开启，0为关闭，默认关闭。 -->
<property name="useCompression">1</property>
<!-- 指定Mysql协议中的报文头长度。默认4。 -->
<property name="packetHeaderSize">4</property>
<!-- 指定Mysql协议可以携带的数据最大长度。默认16M。 -->
<property name="maxPacketSize">16M</property>
<!-- MyCat模拟的Mysql版本号，默认值为5.6版本，如非特需，不要修改这个值，目前支持设置5.5,5.6,5.7版本，其他版本可能会有问题。 -->
<property name="fakeMySQLVersion">5.6.20</property>
<!-- 每次读取留的数量，默认40960。 -->
<property name="processorBufferChunk">40960</property>
<!-- 处理线程数量，默认是cpu数量。 -->
<property name="processors">1</property>
<property name="processorExecutor">32</property>
<!-- 创建共享buffer需要占用的总空间大小。processorBufferChunk*processors*100。 -->
<property name="processorBufferPool">409600</property>
<!-- 默认为0，type 0: DirectByteBufferPool | type 1 ByteBufferArena | type 2 NettyBufferPool -->
<property name="processorBufferPoolType">0</property>
<!-- 二级共享buffer是processorBufferPool的百分比，这里设置的是百分比。 -->
<property name="processorBufferLocalPercent">100</property>
<!-- 默认是65535，64K用于sql解析时最大文本长度 -->
<property name="maxStringLiteralLength">65535</property>
<!-- 全局ID生成方式。(0:为本地文件方式，1:为数据库方式；2:为时间戳序列方式；3:为ZK生成ID；4:为ZK递增ID生成。 -->
<property name="sequnceHandlerType">0</property>
<property name="backSocketNoDelay">1</property>
<property name="frontSocketNoDelay">1</property>
<property name="processorExecutor">16</property>
<!-- 定义MyCat的使用端口，默认值为8066。 -->
<property name="serverPort">8066</property>
<!-- 定义MyCat的管理端口，默认值为9066。 -->
<property name="managerPort">9066</property>
<!-- 指定连接的空闲超时时间。某连接在发起空闲检查下，发现距离上次使用超过了空闲时间，那么这个连接会被回收，就是被直接的关闭掉。默认30分钟，单位毫秒。-->
<property name="idleTimeout">300000</property>
<!-- MyCat服务监听的IP地址，默认值为0.0.0.0。-->
<property name="bindIp">0.0.0.0</property>
<!-- 对后端连接进行空闲、超时检查的时间间隔，默认是300秒，单位毫秒。 -->
<property name="dataNodeIdleCheckPeriod">300000</property>
<property name="frontWriteQueueSize">4096</property>
<property name="processors">32</property>
<!-- 分布式事务开关，0为不过滤分布式事务，1为过滤分布式事务（如果分布式事务内只涉及全局表，则不过滤），2为不过滤分布式事务，但是记录分布式事务日志 -->
<property name="handleDistributedTransactions">0</property>
<!-- off heap for merge/order/group/limit 1开启 0关闭-->
<property name="useOffHeapForMerge">0</property>
<!-- 单位为m -->
<property name="memoryPageSize">64k</property>
<!-- 单位为k -->
<property name="spillsFileBufferSize">1k</property>
<property name="useStreamOutput">0</property>
<!-- 单位为m -->
<property name="systemReserveMemorySize">384m</property>
<!-- 是否采用zookeeper协调切换 -->
<property name="useZKSwitch">false</property>
<!-- XA Recovery Log日志路径 -->
<property name="XARecoveryLogBaseDir">./</property>
<!-- XA Recovery Log日志名称 -->
<property name="XARecoveryLogBaseName">tmlog</property>
<!-- 如果为true的话，严格遵守隔离级别，不会在仅仅只有select语句的时候在事务中切换连接 -->
<property name="strictTxIsolation">false</property>
<property name="useZKSwitch">true</property>
<!-- 如果为0的话，涉及多个DataNode的catlet任务不会跨线程执行 -->
<property name="parallExecute">0</property>
<!-- 前端连接的初始化事务隔离级别，只在初始化的时候使用，后续会根据客户端传递过来的属性对后端数据库连接进行同步。默认为REPEATED_READ，设置值为数字默认3。
READ_UNCOMMITTED = 1;
READ_COMMITTED = 2;
REPEATED_READ = 3;
SERIALIZABLE = 4; -->
<property name="txIsolation">3</property>
<!-- 清理NIOProcessor上前后端空闲、超时和关闭连接的间隔时间。默认是1秒，单位毫秒。 -->
<property name="processorCheckPeriod">1000</property>
<!-- 对后端所有读、写库发起心跳的间隔时间，默认是10秒，单位毫秒。 -->
<property name="dataNodeHeartbeatPeriod">10000</property>
</system>
<!-- 全局SQL防火墙设置 -->
<!-- 白名单可以使用通配符%或着* -->
<!-- 例如<host host="127.0.0.*" user="root"/> -->
<!-- 例如<host host="127.0.*" user="root"/> -->
<!-- 例如<host host="127.*" user="root"/> -->
<!-- 例如<host host="1*7.*" user="root"/> -->
<!-- 这些配置情况下对于127.0.0.1都能以root账户登录 -->
<!--
<firewall>
<whitehost>
<host host="1*7.0.0.*" user="root"/>
</whitehost>
<blacklist check="false">
</blacklist>
</firewall>
-->
<!-- user：用户配置节点
--name：登录的用户名，也就是连接MyCat的用户名。
--password：登录的密码，也就是连接MyCat的密码。
--schemas：数据库名，这里会和schema.xml中的配置关联，多个用逗号分开，例如需要这个用户需要管理两个数据库db1,db2，则配置db1,dbs -->
<user name="root" defaultAccount="true">
<property name="password">123456</property>
<property name="schemas">TESTDB</property>
<property name="defaultSchema">TESTDB</property>
<!--No MyCat Database selected 错误前会尝试使用该schema作为schema，不设置则为null,报错 -->
<!-- 表级DML权限设置 -->
<!-- 对用户的schema以及表进行精细化的DML权限控制 -->
<!-- check：表示是否开启DML权限检查。默认是关闭。server.dtd文件中 <!ELEMENT privileges (schema)*> 说明可以有多个schema的配置。
dml：顺序说明：insert,update,select,delete，0关闭，1开启 -->
<!-- TESTDB的权限是update,select。
tb01的权限是啥都不能干。
tb02的权限是insert,update,select,delete。
其他表默认是udpate,select。 -->
<!--
<privileges check="false">
<schema name="TESTDB" dml="0110" >
<table name="tb01" dml="0000"></table>
<table name="tb02" dml="1111"></table>
</schema>
</privileges>
-->
</user>
<user name="user">
<property name="password">user</property>
<property name="schemas">TESTDB</property>
<property name="readOnly">true</property>
<property name="defaultSchema">TESTDB</property>
</user>
</MyCat:server>
MyCat配置之wrapper.conf
-- 配置jdk所在路径
wrapper.java.command=D:/Program Files/Java/jdk1.8.0_131/bin/java.exe
