PolarDB-X源码解读系列：DML之Insert流程
在阅读本文之前，强烈建议先阅读《PolarDB-X源码解读系列：SQL 的一生》，能够了解一条SQL的执行流程，也能知道GalaxySQL(CN)的各个组件，然后再阅读本文，了解Insert的具体实现过程，加深各个组件的理解。
Insert类的SQL语句的流程可初略分为：解析、校验、优化器、执行器、物理执行(GalaxyEngine执行)。本文将以一条简单的Insert语句通过调试的方式进行解读。
建表语句：
#一个简单的PolarDB-X中的分库分表sbtest
CREATE TABLE `sbtest` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
)dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 2;
#调试语句
insert into sbtest(id) values(100);
解析
连接上PolarDB-X后，执行一条Insert语句insert into sbtest(id) values(100);PolarDB-X接收到该字符串语句后，开始执行该SQL，可见TConnection#executeSQL：
准备执行该SQL语句，ExecutionContext会保留该Sql执行的参数、配置、等上下文信息，该变量会一直陪伴该Sql经过解析、校验、优化器、执行器，直到下发给GalaxyEngine(DN)。
PolarDB-X执行该SQL时，需要先获取执行计划，可见代码TConnection#executeQuery：
ExecutionPlan plan = Planner.getInstance().plan(sql, executionContext);
为了避免执行同一条SQL每次都要解析、校验、优化器等操作，PolarDB-X内置了PlanCache，会在PlanCache中获取该SQL的执行计划，当然，并不是根据纯字符串SQL来进行缓存，而是生成SqlParameterized，如下图所示(Planner#plan)，真正缓存的是sql模板，该类中的sql变量：INSERT INTO sbtest (id)\nVALUES (?)，可适用于类似的语句，？代表可填入的值，不同的值都是同一类SQL语句。
如果PlanCache找不到的话，需要生成新的执行计划，具体代码见PlanCache#getFromCache：
先将字符串通过FastsqlParser解析成抽象语法树，检查有没有语法错误等，生成SqlNode，本条SQL是Insert语句，解析成SqlInsert类，然后继续根据抽象语法树获取执行计划，具体SqlInsert内容为：
简单解释几个变量：
- keywords：关键字，例如：Insert Ignore语句会加Ignore关键字，代表该语句特征；
- source：数据来源，插入数据的来源，这里是values，如果是 Insert ... Select语句，则是select语句；
- updateList：修改信息，例如：Insert ... ON DUPLICATE KEY 语句会把修改信息保存在该变量；
至此，完成了字符串SQL语句到SqlNode的转变，即完成了解析部分。
校验
校验过程即检查SqlNode的语义是否正确，例如表是否存在、列是否存在、类型是否正确等等，具体入口在Planner#getPlan函数中：
SqlNode validatedNode = converter.validate(ast);
便是验证该SQL的有效性，PolarDB-X沿用了Apache Calcite框架，validate的实现也是类似的大框架，包含Scope和Namespace两个概念，在此基础上进行验证，SqlInsert类型的验证入口在SqlValidatorImpl#validateInsert(SqlInsert insert)中:
...
final SqlValidatorNamespace targetNamespace = getNamespace(insert);
validateNamespace(targetNamespace, unknownType);
...
final SqlNode source = insert.getSource();
if (source instanceof SqlSelect) {
final SqlSelect sqlSelect = (SqlSelect) source;
validateSelect(sqlSelect, targetRowType);
} else {
final SqlValidatorScope scope = scopes.get(source);
validateQuery(source, scope, targetRowType);
}
...
大体流程检查两个部分：首先，检查insert into sbtest语句是否正确；然后检查SqlInsert.source部分是否有效。本条SQL是Values，所以检查Values是否有效，如果是Insert ...Select语句，source是SqlSelect，需要检查Select语句是否有效。没有报错，则说明SQL语句语义没有错误，校验通过，可以发现还是SqlInsert：
优化器
在经过优化器之前，还需要将SqlNode(SqlInsert)转成RelNode，大体含义就是将sql语法树转成关系表达式，入口在Planner#getPlan：
RelNode relNode = converter.toRel(validatedNode, plannerContext);
具体转换过程在SqlConverter#toRel：
...
final SqlToRelConverter sqlToRelConverter = new TddlSqlToRelConverter(...);
RelRoot root = sqlToRelConverter.convertQuery(validatedNode, false, true);
...
TddlSqlToRelConverter类是PolarDB-X的转换器，继承Calcite的SqlToRelConverter类，转换SqlInsert的执行过程在TddlSqlToRelConverter#convertInsert(SqlInsert call)：
RelNode relNode = super.convertInsert(call);
if (relNode instanceof TableModify) {
...
}
可以发现， 会调用SqlToRelConverter#convertInsert，在该方法中，会将SqlInsert转成LogicalTableModify，该类的内容如下：
可以注意到几个变量：operation：操作类型；input：输入来源，本条sql是values；
PolarDB-X内部还有新的自己的RelNode，所以还会把RelNode再转成自己定义的RelNode，入口在Planner#getPlan：
ToDrdsRelVisitor toDrdsRelVisitor = new ToDrdsRelVisitor(validatedNode, plannerContext);
RelNode drdsRelNode = relNode.accept(toDrdsRelVisitor);
转换过程在ToDrdsRelVisitor#visit(RelNode other)：
if ((other instanceof LogicalTableModify)) {
...
if (operation == TableModify.Operation.INSERT || ...) {
LogicalInsert logicalInsert = new LogicalInsert(modify);
...
}
}
Insert类型会转成LogicalInsert，就是PolarDB-X内部的RelNode，执行也是基于该类，LogicalInsert的内容如下（还有部分变量不在截图中）：
大多数变量和LogicalTableModify一样，新增了像PolarDB-X特有的gsi相关变量等等。
然后便是经过优化器阶段，优化器执行过程代码在Planner#sqlRewriteAndPlanEnumerate：
private RelNode sqlRewriteAndPlanEnumerate(RelNode input, PlannerContext plannerContext) {
CalcitePlanOptimizerTrace.getOptimizerTracer().get().addSnapshot("Start", input, plannerContext);
//RBO优化
RelNode logicalOutput = optimizeBySqlWriter(input, plannerContext);
CalcitePlanOptimizerTrace.getOptimizerTracer().get()
.addSnapshot("PlanEnumerate", logicalOutput, plannerContext);
//CBO优化
RelNode bestPlan = optimizeByPlanEnumerator(logicalOutput, plannerContext);
// finally we should clear the planner to release memory
bestPlan.getCluster().getPlanner().clear();
bestPlan.getCluster().invalidateMetadataQuery();
return bestPlan;
}
Insert的优化器主要在RBO过程，定义了一些规则，CBO规则对Insert几乎没有改变。可以重点关注RBO的OptimizeLogicalInsertRule规则，会根据GMS（PolarDB-X的元数据管理）的信息来判断该SQL的执行计划，可能会将LogicalInsert转变成其它的RelNode去执行，方便区分不同的SQL执行方式，首先会确定该SQL的执行策略，主要分为三种：
public enum ExecutionStrategy {
/**
* Foreach row, exists only one target partition.
* Pushdown origin statement, with function call not pushable (like sequence call) replaced by RexCallParam.
* Typical for single table and partitioned table without gsi.
*/
PUSHDOWN,
/**
* Foreach row, might exists more than one target partition.
* Pushdown origin statement, with nondeterministic function call replaced by RexCallParam.
* Typical for broadcast table.
*/
DETERMINISTIC_PUSHDOWN,
/**
* Foreach row, might exists more than one target partition, and data in different target partitions might be different.
* Select then execute, with all function call replaced by RexCallParam.
* Typical for table with gsi or table are doing scale out.
*/
LOGICAL;
};
由于本条SQL较为简单，策略是PUSHDOWN，处理过程也比较简单，然后生成InsertWriter，该类负责生成下发到DN的SQL语句，保存在LogicalInsert中，OptimizeLogicalInsertRule处理规则较为细节，感兴趣的可以自行查看onMatch方法。
经过优化器后，还是LogicalInsert类的RelNode，至此，意味着优化器执行完毕。
最终会生成执行计划，在PlanCache#getFromCache，见下图（图中非全部变量）：
ExecutionPlan.plan就是执行计划，可以发现是LogicalInsert，对于简单的Insert，PolarDB-X还会改写执行计划，代码在PlanCache#getFromCache：
BuildFinalPlanVisitor visitor = new BuildFinalPlanVisitor(executionPlan.getAst(), plannerContext);
executionPlan = executionPlan.copy(executionPlan.getPlan().accept(visitor));
insert into sbtest(id) values(100);语句执行BuildFinalPlanVisitor#buildNewPlanForInsert(LogicalInsert logicalInsert, ExecutionContext ec)，因为该Insert语句比较简单，只有一个values，包含拆分键和auto_increment列，只需要根据拆分键就能确定下发到DN的哪一个分片，在CN端无需更多操作，所以会简化执行计划，在BuildFinalPlanVisitor#buildSingleTableInsert转成SingleTableOperation，并保存了分库分表规则，最终的执行计划如下：
执行计划变成SingleTableOperation，至此，执行计划生成完毕。
执行器
SQL语句生成执行计划后，将由执行器进行执行，执行入口在TConnection#executeQuery：
ResultCursor resultCursor = executor.execute(plan, executionContext);
然后会由ExecutorHelper#execute方法执行ExecutionPlan.plan，也就是前面的SingleTableOperation，执行策略有CURSOR、TP_LOCAL、AP_LOCAL、MPP，Insert类型基本都是走CURSOR，接着根据执行计划拿对应的Handler进行处理，具体可查看CommandHandlerFactoryMyImp类，例如：SingleTableOperation是MySingleTableModifyHandler，LogicalInsert是LogicalInsertHandler。会在对应的Handler里面进行执行，一般会返回一个Cursor，Cursor里面会调用真正的执行过程，调用Cursor.next便会获取结果，Insert语句的结果是affect Rows，本条SQL会创建一个
MyPhyTableModifyCursor，入口在MySingleTableModifyHandler#handleInner：
...
MyPhyTableModifyCursor modifyCursor = (MyPhyTableModifyCursor) repo.getCursorFactory().repoCursor(executionContext, logicalPlan);
...
affectRows = modifyCursor.batchUpdate();
...
根据ExecutionContext和SingleTableOperation创建一个MyPhyTableModifyCursor，然后直接执行：
public int[] batchUpdate() {
try {
return handler.executeUpdate(this.plan);
} catch (SQLException e) {
throw GeneralUtil.nestedException(e);
}
}
这里的this.plan就是SingleTableOperation，handler是PolarDB-X的CN与DN间交互的MyJdbcHandler，可以认为是执行物理计划的handler，会根据plan生成真正的物理SQL，下发到DN执行。
由于这条SQL较为简单，CN不需要过多处理，再举一例Insert语句：insert into sbtest(k) values(101),(102);
经过优化器后，该语句的执行计划是LogicalInsert，如下图：
可以发现sqlTemplate为INSERT\nINTO ? (id,k)\nVALUES(?, ?)，表名可能要换成物理表名，同时增加了一列id，因为该列是auto_increment，会有一个全局的sequence表来记录该列的值，才能保证全局唯一，插入的values的参数保留在ExecutionContext的params中，如下图：
id列的值会在真正生成物理执行计划的时候才会去获取，LogicalInsert计划适用LogicalInsertHandler来执行，执行过程：
public Cursor handle(RelNode logicalPlan, ExecutionContext executionContext){
...
LogicalInsert logicalInsert = (LogicalInsert) logicalPlan;
...
if (!logicalInsert.isSourceSelect()) {
affectRows = doExecute(logicalInsert, executionContext, handlerParams);
} else {
affectRows = selectForInsert(logicalInsert, executionContext, handlerParams);
}
...
}
会根据来源是否是Select语句选择不同的执行方式，具体执行过程在LogicalInsertHandler#executeInsert，如下：
...
//生成主表的物理执行计划
final InsertWriter primaryWriter = logicalInsert.getPrimaryInsertWriter();
List inputs = primaryWriter.getInput(executionContext);
...
//如果有GSI，生成GSI表的物理执行计划
final List gsiWriters = logicalInsert.getGsiInsertWriters();
gsiWriters.stream().map(gsiWriter -> gsiWriter.getInput(executionContext))...;
...
//执行所有物理执行计划
final int totalAffectRows = executePhysicalPlan(allPhyPlan, executionContext, schemaName, isBroadcast);
...
主表生成物理执行计划过程中，会先获取id的值，由于id也是拆分键，所以两个values会根据拆分键定位到不同的物理分库分表上，会生成有两个物理执行计划，如下：
其中dbIndex是物理库名，tableNames是物理表名，param保存了这条slqTemplate的参数值，填充上就是完整的SQL，然后执行所有物理执行计划，就完成了该SQL的执行。
物理执行
PolarDB-X中CN与DN的交互都在MyJdbcHandler中，以SingleTableOperation为例，看看具体交互过程：
public int[] executeUpdate(BaseQueryOperation phyTableModify) throws SQLException {
...
//获取物理执行计划的库名和参数
Pair> dbIndexAndParam =
phyTableModify.getDbIndexAndParam(executionContext.getParams() == null ? null : executionContext.getParams()
.getCurrentParameter(), executionContext);
...
//根据库名获取连接
connection = getPhyConnection(transaction, rw, groupName);
...
//根据参数组成字符串SQL
String sql = buildSql(sqlAndParam.sql, executionContext);
...
//根据连接创建prepareStatement
ps = prepareStatement(sql, connection, executionContext, isInsert, false);
...
//设置参数
ParameterMethod.setParameters(ps, sqlAndParam.param);
...
//执行
affectRow = ((PreparedStatement) ps).executeUpdate();
...
}
将物理执行计划发送到DN执行，执行完成后，根据affectRow返回到执行器，最终会把结果返回给用户，至此，一条完整SQL就执行完成。
小结
本文通过调试简单的Insert语句，介绍了PolarDB-X在解析、校验、优化器、执行器对Insert语句的处理，当然，Insert语句也有很多特殊的用法，本文并没有一一概述，感兴趣的同学可以在相应代码处进行查看。
