Sharding-JDBC

数据库优化的几个阶段

表的垂直拆分

是指按功能模块拆分，比如分为订单库、商品库、用户库…这种方式多个数据库之间的表结构不同。

假如你有幸能够在什么经营商、银行等公司上班，你会发现他们一个表，几百个字段都是很常见的事情。所以，应该要进行拆分，拆分准则一般是如下三点:

(1)把不常使用的字段单独放在一张表。

(2)把常使用的字段单独放一张表

(3)经常组合查询的列放在一张表中（联合索引）。

水平拆分

将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同。

实现方法：

(1)顺序拆分：如可以按订单的日前按年份才分，2003年的放在db1中，2004年的db2,以此类推。当然也可以按主键标准拆分。

优点：可部分迁移

缺点：数据分布不均，可能2003年的订单有100W，2008年的有500W。
（2）hash取模
　　优点：数据分布均匀

缺点：数据迁移的时候麻烦;不能按照机器性能分摊数据 。

数据库优化的几个阶段请参考：
https://www.songma.com/news/txtlist_i21939v.html

索引使用门槛
单表数据量达到几十万或上百万已上
分表使用门槛：

单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

分库分表适用场景

分库分表主要用于应对当前互联网常见的两个场景——大数据量和高并发。

1.数据量大时，减少单表查询压力

2.减少单表的访问压力

3.单表数据量上百万至千万，索引性能下降

4.索引也很难在提高性能或者更新、插入数据频繁等。

Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零：

可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
可基于任何第三方的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。

Sharding-JDBC的不足

主要针对于分表，分库对于开发的影响较低。

1.增加了开发的难度，如如何使用分布式id，如何进行调优减少路由表的数目。如何写分库分表的算法等。

2.对于跨表的查询，有时反而会降低性能，而且调试困难。

3.对部分sql语法支持不太好。如分页越是靠后的Limit分页效率就会越低，也越浪费内存。

二、实现原理

Sharding-JDBC的整体架构如下：

分片

1.分片建：
用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：订单表订单ID分片尾数取模分片，则订单ID为分片字段。SQL中如果无分片字段，将执行全路由，性能较差，支持多分片字段。

2.分片算法

分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

精确分片算法（=与IN语句）
PreciseShardingAlgorithm：用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。

其接口定义如下：

public interface PreciseShardingAlgorithm> extends ShardingAlgorithm {
    
    /**
     * Sharding.
     * 
     * @param availableTargetNames available data sources or tables's names
     * @param shardingValue sharding value
     * @return sharding result for data source or table's name
     */
    String doSharding(Collection availableTargetNames, PreciseShardingValue shardingValue);

范围分片算法（BETWEEN AND 语句）
RangeShardingAlgorithm：用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。需要配合StandardShardingStrategy使用。

其接口定义如下：

public interface RangeShardingAlgorithm> extends ShardingAlgorithm {
    
    /**
     * Sharding.
     * 
     * @param availableTargetNames available data sources or tables's names
     * @param shardingValue sharding value
     * @return sharding results for data sources or tables's names
     */
    Collection doSharding(Collection availableTargetNames, RangeShardingValue shardingValue);

3.分片策略：

1.数据源分片策略（DatabaseShardingStrategy）
对应于DatabaseShardingStrategy。用于配置数据被分配的目标数据源。

2.表分片策略（TableShardingStrategy）
对应于TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在与该数据的目标数据源内。

JDBC规范重写
Sharding-JDBC对JDBC规范的重写思路是针对DataSource、Connection、Statement、PreparedStatement和ResultSet五个核心接口封装，将多个真实JDBC实现类集合（如：MySQL JDBC实现/DBCP JDBC实现等）纳入Sharding-JDBC实现类管理。

五大接口的对应实现关系如下

DataSource-----ShardingDataSource

Connection-----ShardingConnection

Statement-----ShardingStatement

PreparedStatement-----ShardingPreparedStatement

ResultSet-----ShardingResultSet

实现原理：

SQL解析—SQL改写-SQL路由–sql执行–结果归并

SQL解析

简单地说就是对sql语句进行语法分析，看是否符合Sharding-JDBC协议下的语法规则。

SQL解析作为分库分表类产品的核心，性能和兼容性是最重要的衡量指标。目前常见的SQL解析器主要有fdb/jsqlparser和Druid。Sharding-JDBC使用Druid作为SQL解析器，经实际测试，Druid解析速度是另外两个解析器的几十倍。

目前Sharding-JDBC支持join、aggregation（包括avg）、order by、 group by、limit、甚至or查询等复杂SQL的解析。目前不支持union、部分子查询、函数内分片等不太应在分片场景中出现的SQL解析。

分析sharding-jdbc源码的词法分析之前，先大概说一下词法分析是干嘛的，后面理解起来就会更容易，例如对于SQL：“/! hello, afei /delete ignore from t_user where user_id=? “而言，词法分析结果如下：

源码分析：

这里只看重要的SQL解析器，对应的源码是SQLParserFactory.newInstance(dbType, lexerEngine.getCurrentToken().getType(), shardingRule, lexerEngine)，lexerEngine.getCurrentToken().getType()就是上面解析得到的第一个token的类型，核心实现源码如下：

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class SQLParserFactory {

    public static SQLParser newInstance(final DatabaseType dbType, final TokenType tokenType, final ShardingRule shardingRule, final LexerEngine lexerEngine) {
        // 第一个token类型一定是默认关键词，否则抛出异常。构造这种异常很简单，只需要定义的SQL以MySQLKeyword中的关键词开头即可，例如"show create table t_order o"
        if (!(tokenType instanceof DefaultKeyword)) {
            throw new SQLParsingUnsupportedException(tokenType);
        }
        // 根据第一个token类型得到具体解析器，且第一个token一定是：select，insert，update，delete，create，alter，drop，truncate中的一个，否则会抛出SQLParsingUnsupportedException异常。构造这种异常很简单，只需要定义的sql以DefaultKeyword中的关键词开头，且不是下面枚举的关键词即可，例如"DATABASE SELECT o.* FROM t_order o"
        switch ((DefaultKeyword) tokenType)  {
            // 从这里可知，为什么前面要调用lexerEngine.nextToken()获取第一个token，SQLParserFactory根据这个token才能确实哪种类型的SQL解析器
            case SELECT:
                return SelectParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case INSERT:
                return InsertParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case UPDATE:
                return UpdateParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case DELETE:
                return DeleteParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case CREATE:
                return CreateParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case ALTER:
                return AlterParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case DROP:
                return DropParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            case TRUNCATE:
                return TruncateParserFactory.newInstance(dbType, shardingRule, lexerEngine);
            default:
                throw new SQLParsingUnsupportedException(lexerEngine.getCurrentToken().getType());
        }
    }
}

从上面的代码可知，得到的SQL解析器的一些主要属性有：

1.数据库类型dbType；
2.分库分表规则shardingRule；
3.词法分析器引擎lexerEngine；
4.判断是什么类型的sql,如是DQL还是DML等

SQL改写
SQL改写分为两部分，一部分是将分表的逻辑表名称替换为真实表名称。另一部分是根据SQL解析结果替换一些在分片环境中不正确的功能。这里具两个例子：

第1个例子是avg计算。在分片的环境中，以avg1 +avg2+avg3/3计算平均值并不正确，需要改写为（sum1+sum2+sum3）/（count1+count2+ count3）。这就需要将包含avg的SQL改写为sum和count，然后再结果归并时重新计算平均值。

第2个例子是分页。假设每10条数据为一页，取第2页数据。在分片环境下获取limit 10, 10，归并之后再根据排序条件取出前10条数据是不正确的结果。正确的做法是将分条件改写为limit 0, 20，取出所有前2页数据，再结合排序条件算出正确的数据。可以看到越是靠后的Limit分页效率就会越低，也越浪费内存。

源码分析：

核心源码就在sharding-jdbc-core模块的com.dangdang.ddframe.rdb.sharding.rewrite目录下，包含两个文件SQLBuilder和SQLRewriteEngine；

public SQLBuilder rewrite(final boolean isRewriteLimit) {
    SQLBuilder result = new SQLBuilder();
    if (sqlTokens.isEmpty()) {
        result.appendLiterals(originalSQL);
        return result;
    }
    int count = 0;
    // 根据Token的beginPosition即出现的位置排序
    sortByBeginPosition();
    for (SQLToken each : sqlTokens) {
        if (0 == count) {
            // 第一次处理：截取从原生SQL的开始位置到第一个token起始位置之间的内容，例如"SELECT x.id FROM table_x x LIMIT 2, 2"这条SQL的第一个token是TableToken，即table_x所在位置，所以截取内容为"SELECT x.id FROM "
            result.appendLiterals(originalSQL.substring(0, each.getBeginPosition()));
        }
        if (each instanceof TableToken) {
            // 看后面的"表名重写分析"
            appendTableToken(result, (TableToken) each, count, sqlTokens);
        } else if (each instanceof ItemsToken) {
            // ItemsToken是指当逻辑SQL有order by，group by这样的特殊条件时，需要在select的结果列中增加一些结果列，例如执行逻辑SQL:"SELECT o.* FROM t_order o where o.user_id=? order by o.order_id desc limit 2,3"，那么还需要增加结果列o.order_id AS ORDER_BY_DERIVED_0 
            appendItemsToken(result, (ItemsToken) each, count, sqlTokens);
        } else if (each instanceof RowCountToken) {
            // 看后面的"rowCount重写分析"
            appendLimitRowCount(result, (RowCountToken) each, count, sqlTokens, isRewriteLimit);
        } else if (each instanceof OffsetToken) {
            // 看后面的"offset重写分析"
            appendLimitOffsetToken(result, (OffsetToken) each, count, sqlTokens, isRewriteLimit);
        } else if (each instanceof OrderByToken) {
            appendOrderByToken(result, count, sqlTokens);
        }
        count++;
    }
    return result;
}

private void sortByBeginPosition() {
    Collections.sort(sqlTokens, new Comparator() {
        // 生序排列
        @Override
        public int compare(final SQLToken o1, final SQLToken o2) {
            return o1.getBeginPosition() - o2.getBeginPosition();
        }
    });
}

从这段源码可知，sql重写主要包括对表名，limit offset, rowNum以及order by的重写（ItemsToken值对select col1, col2 from… 即查询结果列的重写–需要由于ordre by或者group by需要增加一些结果列）；

SQL路由

SQL路由是根据分片规则配置，将SQL定位至真正的数据源（表）。主要分为单表路由、Binding表路由和笛卡尔积路由。

单表路由最为简单，但路由结果不一定落入唯一库（表），因为支持根据between和in这样的操作符进行分片，所以最终结果仍然可能落入多个库（表）。

Binding表可理解为分库分表规则完全一致的主从表。举例说明：订单表和订单详情表都根据订单ID作为分片键，任意时刻分片逻辑均相同。这样的关联查询和单表查询难度和性能相当。

笛卡尔积查询最为复杂，因为无法根据Binding关系定位分片规则的一致性，所以非Binding表的关联查询需要拆解为笛卡尔积组合执行。查询性能较低，而且数据库连接数较高，需谨慎使用。

源码分析：
进入ShardingPreparedStatement类的executeQuery()方法

@Override
public ResultSet executeQuery() throws SQLException {
    ResultSet result;
    try {
        // 核心方法route()，即解析SQL如何路由执行
        Collection preparedStatementUnits = route();
        // 根据路由信息执行SQL
        List resultSets = new PreparedStatementExecutor(
                getConnection().getShardingContext().getExecutorEngine(), routeResult.getSqlStatement().getType(), preparedStatementUnits, getParameters()).executeQuery();
        // 对返回的结果进行merge合并
        result = new ShardingResultSet(resultSets, new MergeEngine(resultSets, (SelectStatement) routeResult.getSqlStatement()).merge());
    } finally {
        clearBatch();
    }
    currentResultSet = result;
    return result;
}

通过上面的源码可知，SQL查询两个核心：路由和结果合并，接下来一一分析sharding-jdbc如何实现；

路由route()核心源码如下：

private Collection route() throws SQLException {
    Collection result = new LinkedList<>();
    // 调用PreparedStatementRoutingEngine中的route()方法，
    //route()方法调用sqlRouter.route(logicSQL, parameters, sqlStatement)
    routeResult = routingEngine.route(getParameters());
    for (SQLExecutionUnit each : routeResult.getExecutionUnits()) {
        SQLType sqlType = routeResult.getSqlStatement().getType();
        Collection preparedStatements;
        if (SQLType.DDL == sqlType) {
            preparedStatements = generatePreparedStatementForDDL(each);
        } else {
            preparedStatements = Collections.singletonList(generatePreparedStatement(each));
        }
        routedStatements.addAll(preparedStatements);
        for (PreparedStatement preparedStatement : preparedStatements) {
            replaySetParameter(preparedStatement);
            result.add(new PreparedStatementUnit(each, preparedStatement));
        }
    }
    return result;
}

SQLRouter接口有两个实现类：DatabaseHintSQLRouter和ParsingSQLRouter，由于这里没有用hint语法强制执行某个库，所以调用ParsingSQLRouter中的route()方法：
ParsingSQLRouter中的route()方法源码如下：

private RoutingResult route(final List