MyBatis启动流程(下)

Mapper.xml 映射文件解析全流程

在上一章分析 mybatis-config.xml 配置文件解析流程的时候我们看到，在 mybatis-config.xml 配置文件中可以定义多个 <mapper> 标签指定 Mapper 配置文件的地址，MyBatis 会为每个 Mapper.xml 映射文件创建一个 XMLMapperBuilder 实例完成解析。

与 XMLConfigBuilder 类似，XMLMapperBuilder也是具体构造者的角色，继承了 BaseBuilder 这个抽象类，解析 Mapper.xml 映射文件的入口是 XMLMapperBuilder.parse() 方法，其核心步骤如下：

执行 configurationElement() 方法解析整个Mapper.xml 映射文件的内容；
获取当前 Mapper.xml 映射文件指定的 Mapper 接口，并进行注册；
处理 configurationElement() 方法中解析失败的 <resultMap> 标签；
处理 configurationElement() 方法中解析失败的 <cache-ref> 标签；
处理 configurationElement() 方法中解析失败的SQL 语句标签。

可以清晰地看到，configurationElement() 方法才是真正解析 Mapper.xml 映射文件的地方，其中定义了处理 Mapper.xml 映射文件的核心流程：

获取 <mapper> 标签中的 namespace 属性，同时会进行多种边界检查；
解析 <cache> 标签；
解析 <cache-ref> 标签；
解析 <resultMap> 标签；
解析 <sql> 标签；
解析 <select>、<insert>、<update>、<delete> 等 SQL 标签。

下面我们就按照顺序逐一介绍这些方法的核心实现。

1. 处理 `<cache>` 标签

我们知道 Cache 接口及其实现是MyBatis 一级缓存和二级缓存的基础，其中，一级缓存是默认开启的，而二级缓存默认情况下并没有开启，如有需要，可以通过<cache>标签为指定的namespace 开启二级缓存。

XMLMapperBuilder 中解析 <cache> 标签的核心逻辑位于 cacheElement() 方法之中，其具体步骤如下：

获取 <cache> 标签中的各项属性（type、flushInterval、size 等属性）；
读取 <cache> 标签下的子标签信息，这些信息将用于初始化二级缓存；
MapperBuilderAssistant 会根据上述配置信息，创建一个全新的Cache 对象并添加到 Configuration.caches 集合中保存。

也就是说，解析 <cache> 标签得到的所有信息将会传给 MapperBuilderAssistant 完成 Cache 对象的创建，创建好的Cache 对象会添加到 Configuration.caches 集合中，这个 caches 字段是一个StrictMap<Cache> 类型的集合，其中的 Key是Cache 对象的唯一标识，默认值是Mapper.xml 映射文件的namespace，Value 才是真正的二级缓存对应的 Cache 对象。

这里我们简单介绍一下 StrictMap的特性。

StrictMap 继承了 HashMap，并且覆盖了 HashMap 的一些行为，例如，相较于 HashMap 的 put() 方法，StrictMap 的 put() 方法有如下几点不同：

如果检测到重复 Key 的写入，会直接抛出异常；
在没有重复 Key的情况下，会正常写入 KV 数据，与此同时，还会根据 Key产生一个 shortKey，shortKey 与完整 Key 指向同一个 Value 值；
如果 shortKey 已经存在，则将 value 修改成 Ambiguity 对象，Ambiguity 对象表示这个 shortKey 存在二义性，后续通过 StrictMap的get() 方法获取该 shortKey 的时候，会抛出异常。

了解了 StrictMap 这个集合类的特性之后，我们回到MapperBuilderAssistant 这个类继续分析，在它的 useNewCache() 方法中，会根据前面解析得到的配置信息，通过 CacheBuilder 创建 Cache 对象。

通过名字你就能猜测到 CacheBuilder 是 Cache 的构造者，CacheBuilder 中最核心的方法是build() 方法，其中会根据传入的配置信息创建底层存储数据的 Cache 对象以及相关的 Cache 装饰器，具体实现如下：

public Cache build() {

    // 将implementation默认值设置为PerpetualCache，在decorators集合中默认添加LruCache装饰器，
    // 都是在setDefaultImplementations()方法中完成的
    setDefaultImplementations();
    // 通过反射，初始化implementation指定类型的对象
    Cache cache = newBaseCacheInstance(implementation, id);
    // 创建Cache关联的MetaObject对象，并根据properties设置Cache中的各个字段
    setCacheProperties(cache);
    // 根据上面创建的Cache对象类型，决定是否添加装饰器
    if (PerpetualCache.class.equals(cache.getClass())) {
        // 如果是PerpetualCache类型，则为其添加decorators集合中指定的装饰器
        for (Class<? extends Cache> decorator : decorators) {
            // 通过反射创建Cache装饰器
            cache = newCacheDecoratorInstance(decorator, cache);
            // 依赖MetaObject将properties中配置信息设置到Cache的各个属性中，同时调用Cache的initialize()方法完成初始化
            setCacheProperties(cache);

        }
        // 根据readWrite、blocking、clearInterval等配置，
        // 添加SerializedCache、ScheduledCache等装饰器
        cache = setStandardDecorators(cache);
    } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
        // 如果不是PerpetualCache类型，就是其他自定义类型的Cache，则添加一个LoggingCache装饰器
        cache = new LoggingCache(cache);
    }
    return cache;

}

2. 处理`<cache-ref>`标签

通过上述介绍我们知道，可以通过 <cache> 标签为每个 namespace 开启二级缓存，同时还会将 namespace 与关联的二级缓存 Cache对象记录到 Configuration.caches 集合中，也就是说二级缓存是 namespace 级别的。但是，在有的场景中，我们会需要在多个 namespace 共享同一个二级缓存，也就是共享同一个 Cache 对象。

为了解决这个需求，MyBatis提供了 <cache-ref>标签来引用另一个 namespace 的二级缓存。cacheRefElement() 方法是处理 <cache-ref> 标签的核心逻辑所在，在 Configuration 中维护了一个 cacheRefMap 字段（HashMap 类型），其中的 Key 是 <cache-ref> 标签所属的namespace 标识，Value 值是 <cache-ref> 标签引用的 namespace 值，这样的话，就可以将两个namespace 关联起来了，即这两个 namespace 共用一个 Cache对象。

这里会使用到一个叫 CacheRefResolver 的 Cache 引用解析器。CacheRefResolver 中记录了被引用的 namespace以及当前 namespace 关联的MapperBuilderAssistant 对象。前面在解析 <cache>标签的时候我们介绍过，MapperBuilderAssistant 会在 useNewCache() 方法中通过 CacheBuilder 创建新的 Cache 对象，并记录到 currentCache 字段。而这里解析 <cache-ref> 标签的时候，MapperBuilderAssistant 会通过 useCacheRef() 方法从 Configuration.caches 集合中，根据被引用的namespace 查找共享的 Cache 对象来初始化 currentCache，而不再创建新的Cache 对象，从而实现二级缓存的共享。

3. 处理`<resultMap>`标签

有关系型数据库使用经验的同学应该知道，select 语句执行得到的结果集实际上是一张二维表，而 Java 是一门面向对象的程序设计语言，在使用 JDBC 的时候，我们需要手动写代码将select 语句的结果集转换成 Java 对象，这是一项重复性很大的操作。

为了将 Java 开发者从这种重复性的工作中解脱出来，MyBatis 提供了 <resultMap> 标签来定义结果集与 Java 对象之间的映射规则。

首先，<resultMap> 标签下的每一个子标签，例如，<column>、<id> 等，都被解析一个 ResultMapping 对象，其中维护了数据库表中一个列与对应 Java 类中一个属性之间的映射关系。

下面是 ResultMapping 中核心字段的含义。

column（String 类型）：当前标签中指定的 column 属性值，指向的是数据库表中的一个列名（或是别名）。
property（String 类型）：当前标签中指定的 property 属性值，指向的是与 column 列对应的属性名称。
javaType（Class<?> 类型）、jdbcType（JdbcType 类型）：当前标签指定的 javaType 属性值和 jdbcType 属性值，指定了 property 字段的 Java 类型以及对应列的 JDBC 类型。
typeHandler（TypeHandler<?> 类型）：当前标签的 typeHandler 属性值，这里指定的 TypeHandler 会覆盖默认的类型处理器。
nestedResultMapId（String类型）：当前标签的 resultMap 属性值，通过该属性我们可以引用另一个 <resultMap> 标签的id，然后由这个被引用的<resultMap> 标签映射结果集中的一部分列。这样，我们就可以将一个查询结果集映射成多个对象，同时确定这些对象之间的关联关系。
nestedQueryId（String 类型）：当前标签的select 属性，我们可以通过该属性引用另一个 <select> 标签中的select 语句定义，它会将当前列的值作为参数传入这个 select 语句。由于当前结果集可能查询出多行数据，那么可能就会导致 select 属性指定的 SQL 语句会执行多次，也就是著名的 N+1 问题。
columnPrefix（String 类型）：当前标签的 columnPrefix 属性值，记录了表中列名的公共前缀。
resultSet（String 类型）：当前标签的 resultSet 属性值。
lazy（boolean 类型）：当前标签的fetchType 属性，表示是否延迟加载当前标签对应的列。

介绍完 ResultMapping 对象（即<resultMap> 标签下各个子标签的解析结果）之后，我们再来看<resultMap> 标签如何被解析。整个 <resultMap> 标签最终会被解析成 ResultMap 对象，它与 ResultMapping 之间的映射关系如下图所示：

通过上图我们可以看出，ResultMap 中有四个集合与 ResultMapping 紧密相连。

resultMappings 集合，维护了整个<resultMap> 标签解析之后得到的全部映射关系，也就是全部 ResultMapping 对象。
idResultMappings 集合，维护了与唯一标识相关的映射，例如，<id> 标签、<constructor> 标签下的 <idArg> 子标签解析得到的 ResultMapping 对象。如果没有定义 <id> 等唯一性标签，则由 resultMappings 集合中全部映射关系来确定一条记录的唯一性，即 idResultMappings 集合与 resulMappings 集合相同。
constructorResultMappings 集合，维护了 <constructor> 标签下全部子标签定义的映射关系。
propertyResultMappings 集合，维护了不带 Constructor 标志的映射关系。

除了上述四个 ResultMapping 集合，ResultMap 中还维护了下列核心字段。

id（String 类型）：当前 <resultMap> 标签的 id 属性值。
type（Class 类型）：当前 <resultMap> 的 type 属性值。
mappedColumns（Set<String> 类型）：维护了所有映射关系中涉及的 column 属性值，也就是所有的列名（或别名）。
hasNestedResultMaps（boolean 类型）：当前 <resultMap> 标签是否嵌套了其他 <resultMap> 标签，即这个映射关系中指定了 resultMap属性，且未指定 resultSet 属性。
hasNestedQueries（boolean 类型）：当前 <resultMap> 标签是否含有嵌套查询。也就是说，这个映射关系中是否指定了 select 属性。
autoMapping（Boolean 类型）：当前 ResultMap 是否开启自动映射的功能。
discriminator（Discriminator 类型）：对应 <discriminator> 标签。

接下来我们开始深入分析 <resultMap> 标签解析的流程。XMLMapperBuilder的resultMapElements() 方法负责解析 Mapper 配置文件中的全部 <resultMap> 标签，其中会通过 resultMapElement() 方法解析单个 <resultMap> 标签。

下面是 resultMapElement() 方法解析 <resultMap>标签的核心流程。

获取 <resultMap> 标签的type 属性值，这个值表示结果集将被映射成 type 指定类型的对象。如果没有指定 type 属性的话，会找其他属性值，优先级依次是：type、ofType、resultType、javaType。在这一步中会确定映射得到的对象类型，这里支持别名转换。
解析<resultMap>标签下的各个子标签，每个子标签都会生成一个ResultMapping 对象，这个 ResultMapping 对象会被添加到resultMappings 集合（List<ResultMapping> 类型）中暂存。这里会涉及 <id>、<result>、<association>、<collection>、<discriminator> 等子标签的解析。
获取 <resultMap> 标签的id 属性，默认值会拼装所有父标签的id、value 或 property 属性值。
获取 <resultMap> 标签的extends、autoMapping 等属性。
创建 ResultMapResolver 对象，ResultMapResolver 会根据上面解析到的ResultMappings 集合以及 <resultMap> 标签的属性构造 ResultMap 对象，并将其添加到 Configuration.resultMaps 集合（StrictMap 类型）中。

（1）解析 `<id>`、`<result>`、`<constructor>`标签

在 resultMapElement() 方法中获取到 id 属性和 type 属性值之后，会调用 buildResultMappingFromContext() 方法解析上述标签得到 ResultMapping 对象，其核心逻辑如下：

获取当前标签的property的属性值作为目标属性名称（如果 <constructor> 标签使用的是 name 属性）；
获取 column、javaType、typeHandler、jdbcType、select 等一系列属性，与获取 property 属性的方式类似；
根据上面解析到的信息，调用 MapperBuilderAssistant.buildResultMapping() 方法创建 ResultMapping 对象。

正如 resultMapElement() 方法核心步骤描述的那样，经过解析得到 ResultMapping 对象集合之后，会记录到resultMappings 这个临时集合中，然后由 ResultMapResolver 调用 MapperBuilderAssistant.addResultMap() 方法创建 ResultMap 对象，将resultMappings 集合中的全部 ResultMapping 对象添加到其中，然后将ResultMap 对象记录到 Configuration.resultMaps 集合中。

下面是 MapperBuilderAssistant.addResultMap() 的具体实现：

public ResultMap addResultMap(

        String id,
        Class<?> type,
        String extend,
        Discriminator discriminator,
        List<ResultMapping> resultMappings,
        Boolean autoMapping) {

    // ResultMap的完整id是"namespace.id"的格式
    id = applyCurrentNamespace(id, false);
    // 获取被继承的ResultMap的完整id，也就是父ResultMap对象的完整id
    extend = applyCurrentNamespace(extend, true);

    if (extend != null) {  // 针对extend属性的处理

        // 检测Configuration.resultMaps集合中是否存在被继承的ResultMap对象
        if (!configuration.hasResultMap(extend)) {
            throw new IncompleteElementException("Could not find a parent resultmap with id '" + extend + "'");

        }

        // 获取需要被继承的ResultMap对象，也就是父ResultMap对象
        ResultMap resultMap = configuration.getResultMap(extend);
        // 获取父ResultMap对象中记录的ResultMapping集合
        List<ResultMapping> extendedResultMappings = new ArrayList<>(resultMap.getResultMappings());
        // 删除需要覆盖的ResultMapping集合
        extendedResultMappings.removeAll(resultMappings);
        // 如果当前<resultMap>标签中定义了<constructor>标签，则不需要使用父ResultMap中记录
        // 的相应<constructor>标签，这里会将其对应的ResultMapping对象删除
        boolean declaresConstructor = false;
        for (ResultMapping resultMapping : resultMappings) {
            if (resultMapping.getFlags().contains(ResultFlag.CONSTRUCTOR)) {
                declaresConstructor = true;
                break;
            }

        }

        if (declaresConstructor) {
            extendedResultMappings.removeIf(resultMapping -> resultMapping.getFlags().contains(ResultFlag.CONSTRUCTOR));

        }
        // 添加需要被继承下来的ResultMapping对象记录到resultMappings集合中
        resultMappings.addAll(extendedResultMappings);

    }

    // 创建ResultMap对象，并添加到Configuration.resultMaps集合中保存
    ResultMap resultMap = new ResultMap.Builder(configuration, id, type, resultMappings, autoMapping)
            .discriminator(discriminator)
            .build();
    configuration.addResultMap(resultMap);
    return resultMap;

}

至于 <constructor>标签的流程，是由XMLMapperBuilder 中的processConstructorElement() 方法实现，其中会先获取 <constructor> 标签的全部子标签，然后为每个标签添加 CONSTRUCTOR 标志（为每个<idArg> 标签添加额外的ID标志），最后通过 buildResultMappingFromContext()方法创建 ResultMapping对象并记录到 resultMappings 集合中暂存，这些 ResultMapping 对象最终也会添加到前面介绍的ResultMap 对象。

（2）解析 `<association>` 和 `<collection>`标签

接下来，我们来介绍解析 <association> 和 <collection>标签的核心流程，两者解析的过程基本一致。前面介绍的 buildResultMappingFromContext() 方法不仅完成了 <id>、<result> 等标签的解析，还完成了 <association> 和 <collection> 标签的解析，其中相关的代码片段如下：

private ResultMapping buildResultMappingFromContext(XNode context, Class<?> resultType, List<ResultFlag> flags) {

    ... // <association>标签中其他属性的解析与<result>、<id>标签类似，这里不再展开
    // 如果<association>标签没有指定resultMap属性，那么就是匿名嵌套映射，需要通过
    //  processNestedResultMappings()方法解析该匿名的嵌套映射
    String nestedResultMap = context.getStringAttribute("resultMap", () ->
            processNestedResultMappings(context, Collections.emptyList(), resultType));
    ... // <association>标签中其他属性的解析与<result>、<id>标签类似，这里不再展开
    // 根据上面解析到的属性值，创建ResultMapping对象
    return builderAssistant.buildResultMapping(resultType, property, column, javaTypeClass, jdbcTypeEnum, nestedSelect, nestedResultMap, notNullColumn, columnPrefix, typeHandlerClass, flags, resultSet, foreignColumn, lazy);

}

这里的 processNestedResultMappings() 方法会递归执行resultMapElement() 方法解析 <association> 标签和 <collection> 标签指定的匿名嵌套映射，得到一个完整的ResultMap 对象，并添加到Configuration.resultMaps集合中。

（3）解析 `<discriminator>` 标签

最后一个要介绍的是 <discriminator> 标签的解析过程，我们将 <discriminator> 标签与 <case> 标签配合使用，根据结果集中某列的值改变映射行为。从 resultMapElement() 方法的逻辑我们可以看出，<discriminator> 标签是由 processDiscriminatorElement() 方法专门进行解析的，具体实现如下：

private Discriminator processDiscriminatorElement(XNode context, Class<?> resultType, List<ResultMapping> resultMappings) {

    // 从<discriminator>标签中解析column、javaType、jdbcType、typeHandler四个属性的逻辑非常简单，这里将这部分代码省略
    Map<String, String> discriminatorMap = new HashMap<>();
    // 解析<discriminator>标签的<case>子标签

    for (XNode caseChild : context.getChildren()) {

        String value = caseChild.getStringAttribute("value");
        // 通过前面介绍的processNestedResultMappings()方法，解析<case>标签，
        // 创建相应的嵌套ResultMap对象
        String resultMap = caseChild.getStringAttribute("resultMap",
                processNestedResultMappings(caseChild, resultMappings, resultType));
        // 记录该列值与对应选择的ResultMap的Id
        discriminatorMap.put(value, resultMap);

    }

    // 创建Discriminator对象
    return builderAssistant.buildDiscriminator(resultType, column, javaTypeClass, jdbcTypeEnum, typeHandlerClass, discriminatorMap);

}

SQL 语句解析全流程

在 Mapper.xml 映射文件中，除了上面介绍的标签之外，还有一类比较重要的标签，那就是 <select>、<insert>、<delete>、<update> 等 SQL 语句标签。虽然定义在 Mapper.xml 映射文件中，但是这些标签是由 XMLStatementBuilder 进行解析的，而不再由 XMLMapperBuilder 来完成解析。

在开始介绍 XMLStatementBuilder 解析 SQL 语句标签的具体实现之前，我们先来了解一下 MyBatis 在内存中是如何表示这些 SQL 语句标签的。在内存中，MyBatis 使用 SqlSource 接口来表示解析之后的 SQL 语句，其中的 SQL 语句只是一个中间态，可能包含动态 SQL 标签或占位符等信息，无法直接使用。SqlSource 接口的定义如下：

public interface SqlSource {
    // 根据Mapper文件或注解描述的SQL语句，以及传入的实参，返回可执行的SQL
    BoundSql getBoundSql(Object parameterObject);
}

MyBatis 在内存中使用 MappedStatement 对象表示上述 SQL 标签。在 MappedStatement 中的 sqlSource 字段记录了 SQL 标签中定义的 SQL 语句，sqlCommandType 字段记录了 SQL 语句的类型（INSERT、UPDATE、DELETE、SELECT 或 FLUSH 类型）。

介绍完表示 SQL 标签的基础类之后，我们来分析 XMLStatementBuilder 解析 SQL 标签的入口方法—— parseStatementNode() 方法，在该方法中首先会根据 id 属性和 databaseId 属性决定加载匹配的 SQL 标签，然后解析其中的<include> 标签和 <selectKey> 标签，相关的代码片段如下：

public void parseStatementNode() {

    // 获取SQL标签的id以及databaseId属性
    String id = context.getStringAttribute("id");
    String databaseId = context.getStringAttribute("databaseId");

    // 若databaseId属性值与当前使用的数据库不匹配，则不加载该SQL标签
    // 若存在相同id且databaseId不为空的SQL标签，则不再加载该SQL标签
    if (!databaseIdMatchesCurrent(id, databaseId, this.requiredDatabaseId)) {
        return;
    }

    // 根据SQL标签的名称决定其SqlCommandType
    String nodeName = context.getNode().getNodeName();
    SqlCommandType sqlCommandType = SqlCommandType.valueOf(nodeName.toUpperCase(Locale.ENGLISH));
    // 获取SQL标签的属性值，例如，fetchSize、timeout、parameterType、parameterMap、
    // resultMap、resultType、lang、resultSetType、flushCache、useCache等。
    // 这些属性的具体含义在MyBatis官方文档中已经有比较详细的介绍了，这里不再赘述
    ... ...
    // 在解析SQL语句之前，先处理其中的<include>标签
    XMLIncludeTransformer includeParser = new XMLIncludeTransformer(configuration, builderAssistant);
    includeParser.applyIncludes(context.getNode());
    // 获取SQL标签的parameterType、lang两个属性
    ... ...
    // 解析<selectKey>标签
    processSelectKeyNodes(id, parameterTypeClass, langDriver);
    // 暂时省略后面的逻辑
    ...
}

1. 处理 `<include>` 标签

在实际应用中，我们会在<sql> 标签中定义一些能够被重用的SQL 片段，在 XMLMapperBuilder.sqlElement() 方法中会根据当前使用的 DatabaseId 匹配 <sql> 标签，只有匹配的 SQL 片段才会被加载到内存。

在解析 SQL 标签之前，MyBatis 会先将 <include> 标签转换成对应的 SQL 片段（即定义在 <sql> 标签内的文本），这个转换过程是在 XMLIncludeTransformer.applyIncludes() 方法中实现的（其中不仅包含了 <include> 标签的处理，还包含了“${}”占位符的处理）。

针对 <include> 标签的处理如下：

查找 refid 属性指向的 <sql> 标签，得到其对应的 Node 对象；
解析 <include> 标签下的 <property> 标签，将得到的键值对添加到 variablesContext 集合（Properties 类型）中，并形成新的 Properties 对象返回，用于替换占位符；
递归执行 applyIncludes()方法，因为在 <sql> 标签的定义中可能会使用 <include> 引用其他 SQL 片段，在 applyIncludes()方法递归的过程中，如果遇到“${}”占位符，则使用 variablesContext 集合中的键值对进行替换；
最后，将 <include> 标签替换成 <sql> 标签的内容。

通过上面逻辑可以看出，<include> 标签和 <sql> 标签是可以嵌套多层的，此时就会涉及 applyIncludes()方法的递归，同时可以配合“${}”占位符，实现 SQL 片段模板化，更大程度地提高 SQL 片段的重用率。

2. 处理 `<selectKey>` 标签

在有的数据库表设计场景中，我们会添加一个自增 ID 字段作为主键，例如，用户 ID、订单 ID 或者这个自增 ID 本身并没有什么业务含义，只是一个唯一标识而已。在某些业务逻辑里面，我们希望在执行 insert 语句的时候返回这个自增 ID 值，<selectKey> 标签就可以实现自增 ID 的获取。<selectKey> 标签不仅可以获取自增 ID，还可以指定其他 SQL 语句，从其他表或执行数据库的函数获取字段值。

parseSelectKeyNode() 方法是解析 <selectKey> 标签的核心所在，其中会解析 <selectKey> 标签的各个属性，并根据这些属性值将其中的 SQL 语句解析成 MappedStatement 对象，具体实现如下：

private void parseSelectKeyNode(String id, XNode nodeToHandle, Class<?> parameterTypeClass, LanguageDriver langDriver, String databaseId) {

    ... // 解析<selectKey>标签的resultType、statementType、keyProperty等属性



    // 通过LanguageDriver解析<selectKey>标签中的SQL语句，得到对应的SqlSource对象

    SqlSource sqlSource = langDriver.createSqlSource(configuration, nodeToHandle, parameterTypeClass);

    SqlCommandType sqlCommandType = SqlCommandType.SELECT;

    // 创建MappedStatement对象

    builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,

            fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,

            resultSetTypeEnum, flushCache, useCache, resultOrdered,

            keyGenerator, keyProperty, keyColumn, databaseId, langDriver, null);

    id = builderAssistant.applyCurrentNamespace(id, false);

    // 创建<selectKey>标签对应的KeyGenerator对象，这个KeyGenerator对象会添加到Configuration.keyGenerators集合中

    MappedStatement keyStatement = configuration.getMappedStatement(id, false);

    configuration.addKeyGenerator(id, new SelectKeyGenerator(keyStatement, executeBefore));

}

3. 处理 SQL 语句

经过 <include> 标签和 <selectKey> 标签的处理流程之后，XMLStatementBuilder 中的 parseStatementNode()方法接下来就要开始处理 SQL 语句了，相关的代码片段之前被省略了，这里我们详细分析一下：

public void parseStatementNode() {

    // 前面是解析<selectKey>和<include>标签的逻辑，这里不再展示
    // 当执行到这里的时候，<selectKey>和<include>标签已经被解析完毕，并删除掉了
    // 下面是解析SQL语句的逻辑，也是parseStatementNode()方法的核心
    // 通过LanguageDriver.createSqlSource()方法创建SqlSource对象
    SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
    // 获取SQL标签中配置的resultSets、keyProperty、keyColumn等属性，以及前面解析<selectKey>标签得到的KeyGenerator对象等，
    // 这些信息将会填充到MappedStatement对象中



    // 根据上述属性信息创建MappedStatement对象，并添加到Configuration.mappedStatements集合中保存
    builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
            fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
            resultSetTypeEnum, flushCache, useCache, resultOrdered,
            keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);

}

这里解析 SQL 语句使用的是 LanguageDriver 接口，其核心实现是 XMLLanguageDriver，继承关系如下图所示

在 createSqlSource() 方法中，XMLLanguageDriver 会依赖 XMLScriptBuilder 创建 SqlSource 对象，XMLScriptBuilder 首先会判断 SQL 语句是否为动态SQL，判断的核心逻辑在 parseDynamicTags()方法中，核心实现如下：

protected MixedSqlNode parseDynamicTags(XNode node) {

    List<SqlNode> contents = new ArrayList<>(); // 解析后的SqlNode结果集合
    NodeList children = node.getNode().getChildNodes();
    // 获取SQL标签下的所有节点，包括标签节点和文本节点
    for (int i = 0; i < children.getLength(); i++) {
        XNode child = node.newXNode(children.item(i));
        if (child.getNode().getNodeType() == Node.CDATA_SECTION_NODE ||
                child.getNode().getNodeType() == Node.TEXT_NODE) {
            // 处理文本节点，也就是SQL语句
            String data = child.getStringBody("");
            TextSqlNode textSqlNode = new TextSqlNode(data);
            // 解析SQL语句，如果含有未解析的"${}"占位符，则为动态SQL
            if (textSqlNode.isDynamic()) {
                contents.add(textSqlNode);
                isDynamic = true; // 标记为动态SQL语句
            } else {
                contents.add(new StaticTextSqlNode(data));
            }

        } else if (child.getNode().getNodeType() == Node.ELEMENT_NODE) {

            // 如果解析到一个子标签，那么一定是动态SQL
            // 这里会根据不同的标签，获取不同的NodeHandler，然后由NodeHandler进行后续解析
            String nodeName = child.getNode().getNodeName();
            NodeHandler handler = nodeHandlerMap.get(nodeName);
            if (handler == null) {
                throw new BuilderException("Unknown element <" + nodeName + "> in SQL statement.");
            }

            // 处理动态SQL语句，并将解析得到的SqlNode对象记录到contents集合中
            handler.handleNode(child, contents);
            isDynamic = true;
        }

    }
    // 解析后的SqlNode集合将会被封装成MixedSqlNode返回
    return new MixedSqlNode(contents);

}

这里使用 SqlNode 接口来表示一条 SQL 语句的不同部分，其中，TextSqlNode 表示的是SQL 语句的文本（可能包含“${}”占位符），StaticTextSqlNode 表示的是不包含占位符的SQL 语句文本。

另外一个新接口是NodeHandler，它有很多实现类，如下图所示：

NodeHandler接口负责解析动态 SQL 内的标签，生成相应的 SqlNode 对象，通过 NodeHandler 实现类的名称，我们就可以大概猜测到其解析的标签名称。以 IfHandler 为例，它解析的就是 <if> 标签，其核心实现如下：

private class IfHandler implements NodeHandler {
    public void handleNode(XNode nodeToHandle, List<SqlNode> targetContents) {
        // 通过parseDynamicTags()方法，解析<if>标签下嵌套的动态SQL
        MixedSqlNode mixedSqlNode = parseDynamicTags(nodeToHandle);
        // 获取<if>标签判断分支的条件
        String test = nodeToHandle.getStringAttribute("test");
        // 创建IfNode对象(也是SqlNode接口的实现)，并将其保存下来
        IfSqlNode ifSqlNode = new IfSqlNode(mixedSqlNode, test);
        targetContents.add(ifSqlNode);
    }

}

完成了对 SQL 语句的解析，得到了相应的 MixedSqlNode对象之后，XMLScriptBuilder 会根据 SQL 语句的类型生成不同的 SqlSource 实现：

public SqlSource parseScriptNode() {
    // 对SQL语句进行解析
    MixedSqlNode rootSqlNode = parseDynamicTags(context);
    SqlSource sqlSource;
    if (isDynamic) { // 根据该SQL是否为动态SQL，创建不同的SqlSource实现
        sqlSource = new DynamicSqlSource(configuration, rootSqlNode);
    } else {
        sqlSource = new RawSqlSource(configuration, rootSqlNode, parameterType);
    }
    return sqlSource;

}