在ShardingSphere中间件的分库分表方案中，Hash取模和Range占了绝大多数。
如果业务发展非常快，可能在初次分库分表后过不了多久就要考虑开始扩容了。例如，原来只分了4个库，但是现在要在原来的基础上再分4个，变成8个库。
当采用Datetime Range（日期时间范围）进行分库分表时，一般不会有扩容问题，因为时间天然就是有序且易分割的。例如按月划分的话，就很容易划分为12个库，保存每年相同月份的数据。
当采用Region Range（地区范围）进行分库分表时，需要对原有数据进行迁移。例如，如果之前按照华中地区来划分的话，现在需要进一步细分为省份，那么就需要将所有的华中数据再次拆分到各个对应的省份数据库中。
这种分片算法不用在配置文件中指定分片键，分片值也不再从SQL中解析，而是从外部手动指定分片库，让SQL在指定的库表中执行。
先创建一个自定义的CustomDBHintShardingAlgorithm类，让它实现HintShardingAlgorithm<Long>接口。
package com.itechthink.strategy;
import org.apache.shardingsphere.api.sharding.hint.HintShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.hint.HintShardingValue;
import java.util.ArrayList;
import java.util.Collection;
/**
* 自定义分库分表策略：Hint分片算法
*
*/
public class CustomHintShardingAlgorithm implements HintShardingAlgorithm<Long> {
/**
* @param dataSourceNames 数据源集合
* 在分库时值为所有分片库的集合 databaseNames
* 分表时为对应分片库中所有分片表的集合 tablesNames
* @param hitShardingValue 分片属性
* logicTableName 逻辑表名
* columnName 分片健，在Hint分片策略下值为""
* value 从SQL中解析出的分片健的值，用于取模判断
* HintShardingAlgorithm 不再从SQL解析中获取值，而是直接通过hintManager.addTableShardingValue("t_order", 1)参数进行指定
*/
@Override
public Collection<String> doSharding(Collection<String> dataSourceNames, HintShardingValue<Long> hitShardingValue) {
Collection<String> result = new ArrayList<>();
for (String datasourceName : dataSourceNames) {
for (Long shardingValue : hitShardingValue.getValues()) {
String value = String.valueOf(shardingValue % dataSourceNames.size());
if (datasourceName.endsWith(value)) {
result.add(datasourceName);
}
}
}
return result;
}
}这种分片算法支持=、IN和BETWEEN AND的分片操作，并且支持多分片键。
这种算法不同的分片键之间可能会有比较复杂的关系，所以ShardingSphere未做过多封装，全由开发者自己实现。
先创建一个自定义的CustomComplexShardingAlgorithm类，让它实现ComplexKeysShardingAlgorithm<Long>接口。
前面一直使用的都是称为inline（行表达式）分片策略，但除此之外，ShardingSphere还有其他四类分片策略：Standard（标准分片策略）、Composite（复合分片策略）、Hint（Hint分片策略）和不分片策略。
Standard（标准分片策略）只支持单字段分片键，通过PreciseShardingAlgorithm实现精准分片。
为了验证分库分表之后的查询效果，可以来做个测试，分别验证一下通过分片键执行查询和不通过分片键的简单查询。
通过数据库终端从itechthink_order_0、itechthink_order_1和itechthink_order_2这三个数据库中任意选择一张t_order表的任意一条数据，拷贝它的分片键字段id和普通字段tradeno的值。
之前说过，所谓广播表其实就是一种配置表或字典表，这种表数据量不大，但很多地方都需要。
先创建一张配置表。
-- 依次在`itechthink_order_0`、`itechthink_order_1`和`itechthink_order_2`中执行以下建表语句
> DROP TABLE IF EXISTS t_config;
> CREATE TABLE t_config (
id BIGINT(20) NOT NULL COMMENT '配置编码',
ckey VARCHAR(512) DEFAULT NULL COMMENT '配置key',
cvalue VARCHAR(512) DEFAULT NULL COMMENT '配置value',
type VARCHAR(128) DEFAULT NULL COMMENT '配置类型',
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '配置表';之前的分表实践只是将数据分到了不同的表中，现在需要更进一步。
先根据userid将数据划分到不同的数据库中。
再根据订单id将数据划分到不同的数据表中。
先清空itechthink_order_0、itechthink_order_1和itechthink_order_2这三个数据库中所有t_order表的数据。
虽然使用MySQL自带的主键自增很简单，但是完全无法满足实际生产环境中的要求，这就是分布式系统中经典的全局唯一ID（Globally Unique Identifier，GUID）问题。
目前为止，这个问题的解决办法归纳起来有七、八种，包括UUID、单库自增、集群自增、号段自增、Redis自增、雪花算法、国内开源算法等诸多方案。
使用ShardingSphere实现将t_order的数据划分到两张表里。
首先创建三个数据库itechthink_order_0、itechthink_order_1和itechthink_order_2。
-- 创建数据库
> DROP DATABASE IF EXISTS itechthink_order_0;
> CREATE DATABASE IF NOT EXISTS itechthink_order_0 DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;
> DROP DATABASE IF EXISTS itechthink_order_1;
> CREATE DATABASE IF NOT EXISTS itechthink_order_1 DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;
> DROP DATABASE IF EXISTS itechthink_order_2;
> CREATE DATABASE IF NOT EXISTS itechthink_order_2 DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;ShardingSphere有一些自己独特的分库分表术语，必须搞清楚它们的意思才能玩得转。
数据节点Node：是数据分片的最小单元，由数据源名称和数据表组成，例如：ds_0.t_order_0。