配置：schema文件rule字段，rule文件name字段
（1）分片枚举：sharding-by-intfile
（2）主键范围：auto-sharding-long
（3）一致性hash：sharding-by-murmur
（4）字符串hash解析：sharding-by-stringhash
（5）按日期（天）分片：sharding-by-date
（6）按单月小时拆分：sharding-by-hour
（6）自然月分片：sharding-by-month
--------常见的10种分片方法--------
1、枚举法
<tableRule name="sharding-by-intfile">
<rule>
<columns>user_id</columns>
<algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name="hash-int" class="io.mycat.route.function.PartitionByFileMap">
<property name="mapFile">partition-hash-int.txt</property>
<property name="type">0</property>
<property name="defaultNode">0</property>
</function>
理解：
切分规则根据文件(partition-hash-int.txt)。此种分片规则理解为枚举分区，会比较适合于取值固定的场合，比如说性别（0,1），省份（固定值）。
优点：
用逗号分隔可以把多个值放在一个分区里面。
缺点：
其他非枚举情况不适合。
枚举分区：sharding-by-intfile
2、范围约定
<tableRule name="auto-sharding-long">
<rule>
<columns>user_id</columns>
<algorithm>rang-long</algorithm>
</rule>
</tableRule>
<function name="rang-long" class="io.mycat.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
</function>
理解：
切分规则根据文件(autopartition-long.txt)。一种范围切分的方式，制定基准列的取值范围，然后把这一范围的所有数据都放到一个DN上面。
优点：
适用于整体数量可知或总数量为固定值的情况。
缺点：
dn划分节点是事先建好的，需要扩展时比较麻烦。
潜在的问题，如果在短时间发生海量的顺序插入操作，而每一个DN（分库）设定的数量比较高(比如说一个DN设定的放1000W条数据),那么在这个时候,会出现某一个DN（分库）IO压力非常高，而其他几个DN（分库）完全没有IO操作，就会出现类似于DB中常见的热块/热盘的现象。
3、求模法
<tableRule name="mod-long">
<rule>
<columns>user_id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<function name="mod-long" class="io.mycat.route.function.PartitionByMod">
<!-- how many data nodes -->
<property name="count">3</property>
</function>
理解：
切分规则根据配置中输入的数值n。此种分片规则将数据分成n份（通常dn节点也为n），从而将数据均匀的分布于各节点上。
优点：
这种策略可以很好的分散数据库写的压力。比较适合于单点查询的情景。
缺点：
一旦出现了范围查询，就需要MyCAT去合并结果，当数据量偏高的时候，这种跨库查询+合并结果消耗的时间有可能会增加很多，尤其是还出现了order by的时候。
4、固定分片hash算法
<tableRule name="rule1">
<rule>
<columns>user_id</columns>
<algorithm>func1</algorithm>
</rule>
</tableRule>
<function name="func1" class="io.mycat.route.function.PartitionByLong">
<property name="partitionCount">2,1</property>
<property name="partitionLength">256,512</property>
</function>
理解：
切分规则根据配置中输入的数值对。上面columns 标识将要分片的表字段，algorithm 分片函数，partitionCount 分片个数列表，partitionLength 分片范围列表。（均分时比求模法更灵活）
分区长度：默认为最大2^n=1024 ,即最大支持1024分区
约束 :count,length两个数组的长度必须是一致的。
优点：
这种策略比较灵活，可以均匀分配也可以非均匀分配，各节点的分配比例和容量大小由count,length两个参数决定。
缺点：
跟求模法类似。
5、日期列分区法
<tableRule name="sharding-by-date">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-date</algorithm>
</rule>
</tableRule>
<function name="sharding-by-date" class="io.mycat.route.function..PartitionByDate">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2014-01-01</property>
<property name="sPartionDay">10</property>
</function>
理解：
切分规则根据配置中输入的各项值。配置中配置了格式，开始日期，分区天数，即默认从开始日期算起，分隔10天一个分区。
6、通配取模
<tableRule name="sharding-by-pattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-pattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern" class="io.mycat.route.function.PartitionByPattern">
<property name="patternValue">256</property>
<property name="defaultNode">2</property>
<property name="mapFile">partition-pattern.txt</property>
</function>
理解：
切分规则根据配置中输入的数值以及文件（partition-pattern.txt）。patternValue 即求模基数，defaoultNode 默认节点，如果不配置了默认，则默认是0即第一个结点。配置文件中，1-32 即代表id%256后分布的范围，如果在1-32则在分区1，其他类推，如果id非数字数据，则会分配在defaoultNode 默认节点配置文件中，1-32 即代表id%256后分布的范围，如果在1-32则在分区1，其他类推，如果id非数字数据，则会分配在defaoultNode 默认节点。
优点：
这种策略可以很好的分散数据库写的压力。比较适合于单点查询的情景。
缺点：
一旦出现了范围查询，就需要MyCAT去合并结果，当数据量偏高的时候，这种跨库查询+合并结果消耗的时间有可能会增加很多，尤其是还出现了order by的时候。
7、ASCII求模通配
<tableRule name="sharding-by-prefixpattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-prefixpattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern" class="io.mycat.route.function.PartitionByPrefixPattern">
<property name="patternValue">256</property>
<property name="prefixLength">5</property>
<property name="mapFile">partition-pattern.txt</property>
</function>
理解：
切分规则根据配置中输入的数值及文件（partition-pattern.txt）。patternValue 即求模基数，prefixLength ASCII 截取的位数。此种方式类似方式6通配取模只不过采取的是将列种获取前prefixLength位列所有ASCII码的和进行求模sum%patternValue ,获取的值，在通配范围内的也就是分片数。
8、编程指定
<tableRule name="sharding-by-substring">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-substring</algorithm>
</rule>
</tableRule>
<function name="sharding-by-substring" class="io.mycat.route.function.PartitionDirectBySubString">
<property name="startIndex">0</property> <!-- zero-based -->
<property name="size">2</property>
<property name="partitionCount">8</property>
<property name="defaultPartition">0</property>
</function>
理解：
此方法为直接根据字符子串（必须是数字）计算分区号（由应用传递参数，显式指定分区号）。
例如id=05-100000002在此配置中代表根据id中从startIndex=0，开始，截取siz=2位数字即05，05就是获取的分区，如果没传默认分配到defaultPartition。
9、字符串拆分hash解析
<tableRule name="sharding-by-stringhash">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-stringhash</algorithm>
</rule>
</tableRule>
<function name="sharding-by-substring" class="io.mycat.route.function.PartitionByString">
<property name=length>512</property> <!-- zero-based -->
<property name="count">2</property>
<property name="hashSlice">0:2</property>
</function>
理解：
函数中length代表字符串hash求模基数，count分区数，hashSlice hash预算位
即根据子字符串 hash运算。
10、一致性hash
<tableRule name="sharding-by-murmur">
<rule>
<columns>user_id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
<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>
优点：
一致性hash预算有效解决了分布式数据的扩容问题，前1-9中id规则都多少存在数据扩容难题，而10规则解决了数据扩容难点
上述整理的分片规则，部分验证、详细的理解以及优缺点信息还未补全，希望能与大家共同学习探讨填补空缺。