匿名通过本文主要向大家介绍了MySQL，MyCAT，rule等相关知识,希望本文的分享对您有所帮助
之前已经介绍过了schema的作用了，这一篇会把rule和server一起介绍~
首先是rule，在这个文件里面会详细的制定多种分片的规则，这次只抽出一些使用率比较高的方法，先上配置文件的内容
可以简单看一下，在截图的上半部分描述的是rule的定义，在下半部分，是rule对应的实际切分规则，这里总工介绍下面四种切分方式~murmur已坑~
-------------------------------------------------------------------------------------------Hash-int---------------------------------------------------------------------------------
先看hash-int，在这一条切分规则的下面，有一个mapfile，这代表着，这个切分规则是根据partition-hash-int的内容来决定的，那么看一下这个文本文件
很简单的内容，这代表着切分使用的基准列里面，值为10000的时候，放在第一个DN里面（dn1），值为10010的时候，放在第二个DN里面（dn2）
可以看一下实际效果
看一下MyCAT的Debug日志，这两条语句被分配到了dn1和dn2上面，数据库里面也插入了相对应的数据
那么~问题来了（挖掘机滚粗~），如果插入的数据中，基准列的取值不是这个文件里面写明的值，会是什么效果？
直截了当的报错了~
好了，hash-int的这种切分规则，大体上可以理解为枚举分区，会比较适合于取值固定的场合，比如说性别（0,1），省份（固定值，短时间不会收复日本省吧~），渠道商 or 各种平台的ID
而且，用逗号分隔可以把多个值放在一个分区里面，所以可以根据实际的数据量/流量/访问量来综合制定切分策略；
缺点：毕竟不是全能战士╮(╯_╰)╭
-------------------------------------------------------------------------------------------range-long---------------------------------------------------------------------------------
第二种切分方式，range-long，仔细一看的话，和hash-int是比较像的，也是由特定的文件来决定切分策略，所以还是去看一下文件的内容
从文件内容可以看出，这是一种范围切分的方式，制定基准列的取值范围，然后把这一范围的所有数据都放到一个DN上面，这种方式和hash-int基本一致，就不截图了（懒癌晚期，时间不够了！）
这种切分策略，个人感觉在业务数据库里面的使用场景会少一些，因为这种切分方式需要预定好整体的数量，这就决定了那种无限增长的数据不能用这个，毕竟要改动这个切分策略会很麻烦
真要用起来，感觉也就对自增主键用，然后按照一定的数量来均匀切分，比如那种一天固定X条数据的业务（温度采集？数据采集？之类的情况），然后提前建好多个DN（库）。
当然，也存在一种潜在的问题，如果在短时间发生海量的顺序插入操作，而每一个DN（分库）设定的数量比较高(比如说一个DN设定的放1000W条数据),那么在这个时候,会出现某一个DN（分库）IO压力非常高，而其他几个DN（分库）完全没有IO操作，就会出现类似于DB中常见的热块/热盘的现象，而MySQL经常用自增主键，所以使得MySQL的表出现大量“顺序”插入的机会会多很多。
--------------------------------------------------------------------------------------------mod-long-----------------------------------------------------------------------------------
mod-long，从mod来看这应该是一种取余数的方法，来看一下具体配置的信息
count=4，这是代表着总共把数据切分成四份，一般是和具体的DN数量对应，从而达到把数据均匀的分布在四个DN上（当然，count<dn数量也没什么问题）
看一下实际的效果
看一下MyCAT的Debug日志，看看MyCAT是如何处理的
采用这种取余数的方式时，这四条数据分别插入了四个DN（库），而且可以看到，顺序插入时，数据是被均匀的分散在多个DN（库）上面
相比较于上面的range的方法，这种切分策略会更好的分散数据库写的压力，但是问题也很明显，一旦出现了范围查询，就需要MyCAT去合并结果，当数据量偏高的时候，这种跨库查询+合并结果消耗的时间有可能会增加很多，尤其是还出现了order by的时候。
所以这种切分策略会比较适合于单点查询的情景，比如说.....我也不知道......真的不知道,也许在银行,查询个人账户信息的时候,一些和用户信息的表可以做好冗余,然后利用这种方式来提供更为高效的查询(毕竟银行的用户数量多,恩恩~)
--------------------------------------------------------------------------------partition-by-long----------------------------------------------------------------------------------
partition-by-long,处于range-long和mod-long之间的一个略微折中的
首先是rule，在这个文件里面会详细的制定多种分片的规则，这次只抽出一些使用率比较高的方法，先上配置文件的内容
可以简单看一下，在截图的上半部分描述的是rule的定义，在下半部分，是rule对应的实际切分规则，这里总工介绍下面四种切分方式~murmur已坑~
-------------------------------------------------------------------------------------------Hash-int---------------------------------------------------------------------------------
先看hash-int，在这一条切分规则的下面，有一个mapfile，这代表着，这个切分规则是根据partition-hash-int的内容来决定的，那么看一下这个文本文件
很简单的内容，这代表着切分使用的基准列里面，值为10000的时候，放在第一个DN里面（dn1），值为10010的时候，放在第二个DN里面（dn2）
可以看一下实际效果
看一下MyCAT的Debug日志，这两条语句被分配到了dn1和dn2上面，数据库里面也插入了相对应的数据
那么~问题来了（挖掘机滚粗~），如果插入的数据中，基准列的取值不是这个文件里面写明的值，会是什么效果？
直截了当的报错了~
好了，hash-int的这种切分规则，大体上可以理解为枚举分区，会比较适合于取值固定的场合，比如说性别（0,1），省份（固定值，短时间不会收复日本省吧~），渠道商 or 各种平台的ID
而且，用逗号分隔可以把多个值放在一个分区里面，所以可以根据实际的数据量/流量/访问量来综合制定切分策略；
缺点：毕竟不是全能战士╮(╯_╰)╭
-------------------------------------------------------------------------------------------range-long---------------------------------------------------------------------------------
第二种切分方式，range-long，仔细一看的话，和hash-int是比较像的，也是由特定的文件来决定切分策略，所以还是去看一下文件的内容
从文件内容可以看出，这是一种范围切分的方式，制定基准列的取值范围，然后把这一范围的所有数据都放到一个DN上面，这种方式和hash-int基本一致，就不截图了（懒癌晚期，时间不够了！）
这种切分策略，个人感觉在业务数据库里面的使用场景会少一些，因为这种切分方式需要预定好整体的数量，这就决定了那种无限增长的数据不能用这个，毕竟要改动这个切分策略会很麻烦
真要用起来，感觉也就对自增主键用，然后按照一定的数量来均匀切分，比如那种一天固定X条数据的业务（温度采集？数据采集？之类的情况），然后提前建好多个DN（库）。
当然，也存在一种潜在的问题，如果在短时间发生海量的顺序插入操作，而每一个DN（分库）设定的数量比较高(比如说一个DN设定的放1000W条数据),那么在这个时候,会出现某一个DN（分库）IO压力非常高，而其他几个DN（分库）完全没有IO操作，就会出现类似于DB中常见的热块/热盘的现象，而MySQL经常用自增主键，所以使得MySQL的表出现大量“顺序”插入的机会会多很多。
--------------------------------------------------------------------------------------------mod-long-----------------------------------------------------------------------------------
mod-long，从mod来看这应该是一种取余数的方法，来看一下具体配置的信息
count=4，这是代表着总共把数据切分成四份，一般是和具体的DN数量对应，从而达到把数据均匀的分布在四个DN上（当然，count<dn数量也没什么问题）
看一下实际的效果
看一下MyCAT的Debug日志，看看MyCAT是如何处理的
采用这种取余数的方式时，这四条数据分别插入了四个DN（库），而且可以看到，顺序插入时，数据是被均匀的分散在多个DN（库）上面
相比较于上面的range的方法，这种切分策略会更好的分散数据库写的压力，但是问题也很明显，一旦出现了范围查询，就需要MyCAT去合并结果，当数据量偏高的时候，这种跨库查询+合并结果消耗的时间有可能会增加很多，尤其是还出现了order by的时候。
所以这种切分策略会比较适合于单点查询的情景，比如说.....我也不知道......真的不知道,也许在银行,查询个人账户信息的时候,一些和用户信息的表可以做好冗余,然后利用这种方式来提供更为高效的查询(毕竟银行的用户数量多,恩恩~)
--------------------------------------------------------------------------------partition-by-long----------------------------------------------------------------------------------
partition-by-long,处于range-long和mod-long之间的一个略微折中的