深入理解Mybatis分库分表执行原理

深入理解Mybatis分库分表执行原理

 探究分库分表场景下Mybatis是如何将mapper.xml中sql的逻辑表，转换成实际执行时的物理表。 

前言

工作多年，分库分表的场景也见到不少了，但是我仍然对其原理一知半解。趁着放假前时间比较富裕，我想要解答三个问题：

为什么mybatis的mapper.xml文件里的sql不需要拼接表名中的分表？

mybatis是如何识别分表位的？

最近工作中遇到的问题：为什么我的三表join会报错找不到表？为了不影响项目上线时间，我不得不在mapper.xml中用${}拼接其中的一个逻辑表对应的物理表表名，引入了SQL注入的风险。

带着问题，我花了不少时间深入了读了一下这部分的源码，终于搞清楚了，借本文分享一下。

本文主要环境是mybatis-plus-boot-starter 3.4.3，不过用的基本上仍然是mybatis的特性。

流程图

以查询为例，可以先看下流程图，大致了解一下整个过程。

关键的类和对象

在流程图里出现了一些类和其实例化的对象，有必要选其中关键的介绍一下。

MappedStatement

类全名org.apache.ibatis.mapping.MappedStatement，是一个final类。不要被名字误导，它和JDBC API中的java.sql.Statement没有实现关系。后者用于执行一条静态SQL并返回结果。

MappedStatement用来维护一个mapper中一个方法（对应一个sql）相关的信息，也就是将xml中的sql实例化成一个对象：

生成时机

使用sql的id通过MybatisConfiguration/Configuration获取。后者内部的Map(mappedStatements)会持有所有的mapper中的语句。

BoundSql

类全名：org.apache.ibatis.mapping.BoundSql

主要用于存储 SQL 语句以及该 SQL 语句所需的参数等信息。

如下图中：

sql字段是经过处理的sql

已经将${}直接替换为实际值，这也就会导致注入风险

#{}则使用?占位

parameterMappings记录参数的映射方法

parameterObject实际的参数值，对应的是java的mapper接口类里的参数。比如接口是9个参数，这里就是18个，其中paramxx是原参数全部用新key存储但是值没变的。这些参数不一定是sql里的?占位符所用到的，可能会多一些。

生成时机

Executor通过MapperStatement生成。

Connection

全名：java.sql.Connection，是JDBC API的一个核心接口。它的功能是：

建立与数据库的连接

创建执行对象，用于执行SQL语句的对象，也就是各种各样的Statement

管理事务，包括开启、提交、回滚。本文以查询为例，探讨分表的路由的原理，因此不会对事务相关话题做展开。

应用配置的是分库分表数据源，对应地，实例化的Connection对象是ShardingSphereConnection，如下：

展开dataSourceMap的value，可以看到更多数据源的配置，包括连接超时时间、jdbcUrl，db的用户名和明文的密码。如果运行容器是Springboot，那么这些配置可以在application.properties里看到。

Statement/ShardingSpherePreparedStatement

Statement接口在jdbc中的地位也很重要，它用于执行一条静态SQL并返回结果。

在分库分表的场景，它会生成各种中间过程的上下文Context，比如ExecutionContext、TrafficContext、RouteContext等，流程图中的LogicSQL也可以看作是一种上下文。Logic的sqlStatementContext把原始SQL进行了结构化的解析，比如from、where、group by等。在from字段可以进行多级的join嵌套，比如下图join的left是另一个join，right是一个表（逻辑表）：

对于LogicSQL的where属性，其中的参数会用于参与库表的分片计算。

Statement也会借助其他的工具类，如SQLCheckEngine、KernelProcessor做处理，其中最关键的一点是，在KernelProcessor中生成ExecutionContext的方法内，生成RouteContext时获取物理表名：

public ExecutionContext generateExecutionContext(final LogicSQL logicSQL, final ShardingSphereMetaData metaData, final ConfigurationProperties props) {

    RouteContext routeContext = route(logicSQL, metaData, props);

    SQLRewriteResult rewriteResult = rewrite(logicSQL, metaData, props, routeContext);

    ExecutionContext result = createExecutionContext(logicSQL, metaData, routeContext, rewriteResult);

    logSQL(logicSQL, props, result);

    return result;

}

上面的route()中，也包含了很多步：

WhereClauseShardingConditionEngine从Logic SQL的from属性获取分表相关的属性和值的代码如下

public List createShardingConditions(final SQLStatementContext sqlStatementContext, final List