MyBatis 的 SQL 执行流程不清楚？看完这一篇就够了！，kafka 视频教程下载

极客good

关注

发布于: 刚刚

3、然后会继续调用自己的 parseConfiguration 来解析配置文件，这里面就会分别去解析全局配置文件的顶级节点，其他的我们先不看，我们直接看最后解析 mappers 节点

4、继续调用自己的 mapperElement 来解析 mappers 文件（这个方法比较长，为了方便截图完整，所以把字体缩小了 1 号），可以看到，这里面分了四种方式来解析 mappers 节点的配置，对应了 4 种 mapper 配置方式，而其中红框内的两种方式是直接配置的 xml 映射文件，蓝框内的两种方式是解析直接配置 Mapper 接口的方式，从这里也可以说明，不论配置哪种方式，最终 MyBatis 都会将 xml 映射文件和 Mapper 接口进行关联。

5、我们先看第 2 种和第 3<typo id="typo-1555" data-origin="中" ignoretag="true">中</typo>（直接配置 xml 映射文件的解析方式），会构建一个 XMLMapperBuilder 对象并调用其 parse 方法。

但是这里有一个问题，如果有多重继承或者多重依赖时在这里是可能会无法被完全解析的，比如说三个映射文件互相依赖，那么 if 里面(假设是最坏情况)只能加载 1 个，失败 2 个，然后走到下面 if 之外的代码又只能加载 1 个，还有 1 个会失败(如下代码中，只会处理 1 次，再次失败并不会继续加入 incompleteResultMaps)：

当然，这个还是会被解析的，后面执行查询的时候会再次通过不断遍历去全部解析完毕，不过有一点需要注意的是，互相引用这种是会导致解析失败报错的，所以在开发过程中我们应该避免循环依赖的产生。

6、解析完映射文件之后，调用自身方法 bindMapperForNamespace，开始绑定 Mapper 接口和映射文件：

7、调用 Configuration 对象的 addMapper

8、调用 Configuration 对象的属性 MapperRegistry 内的 addMapper 方法，这个方法就是正式将 Mapper 接口添加到 knownMappers，所以上面 getMapper 可以直接获取：

到这里我们就完成了 Mapper 接口和 xml 映射文件的绑定

9、注意上面红框里面的代码，又调用了一次 parse 方法，这个 parse 方法主要是解析注解，比如下面的语句：

@Select("select * from lw_user")List<LwUser> listAllUser();

所以这个方法里面会去解析 @Select 等注解，需要注意的是，parse 方法里面会同时再解析一次 xml 映射文件，因为上面我们提到了 mappers 节点有 4 种配置方式，其中两种配置的是 Mapper 接口，而配置 Mapper 接口会直接先调用 addMapper 接口，并没有解析映射文件，所以进入注解解析方法 parse 之中会需要再尝试解析一次 XML 映射文件。

解析完成之后，还会对 Mapper 接口中的方法进行解析，并将每个方法的全限定类名作为 key 存入存入 Configuration 中的 mappedStatements 属性。

需要指出的是，这里存储的时候，同一个 value 会存储 2 次，一个全限定名作为 key，另一个就是只用方法名(sql 语句的 id)来作为 key：

所以最终 mappedStatements 会是下面的情况：

事实上如果我们通过接口的方式来编程的话，最后来 getStatement 的时候，都是根据全限定名来取的，所以即使有重名对我们也没有影响，而之所以要这么做的原因其实还是为了兼容早期版本的用法，那就是不通过接口，而是直接通过方法名的方式来进行查询：

session.selectList("com.lonelyWolf.mybatis.mapper.UserMapper.listAllUser");

这里如果 shortName 没有重复的话，是可以直接通过简写来查询的：

session.selectList("listAllUser");

但是通过简写来查询一旦 shortName 重复了就会抛出以下异常：

这里的异常其实就是 StrickMap 的 get 方法抛出来的：

sql 执行流程分析

上面我们<typo id="typo-2941" data-origin="讲" ignoretag="true">讲</typo>到了，获取到的 Mapper 接口实际上被包装成为了代理对象，所以我们执行查询语句肯定是执行的代理对象方法，接下来我们就以 Mapper 接口的代理对象 MapperProxy 来分析一下查询流程。

整个 sql 执行流程可以分为两大步骤：

一、寻找 sql
二、执行 sql 语句

寻找 sql

首先还是来看一下寻找 sql 语句的时序图：

1、了解代理模式的应该都知

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

复制代码

道，调用被代理对象的方法之后实际上执行的就是代理对象的 invoke 方法

2、因为我们这里并没有调用 Object 类中的方法，所以肯定走的 else。else 中会继续调用 MapperProxy 内部类 MapperMethodInvoker 中的方法 cachedInvoker，这里面会有一个判断，判断一下我们是不是 default 方法，因为 Jdk1.8 中接口中可以新增 default 方法，而 default 方法是并不是一个抽象方法，所以也需要特殊处理（刚开始会从缓存里面取，缓存相关知识我们这里先不讲，后面会单独写一篇来分析一下缓存)）。

3、接下来，是构造一个 MapperMethod 对象,这个对象封装了 Mapper 接口中对应的方法信息以及对应的 sql 语句信息：

这里面就会把要执行的 sql 语句，请求参数，方法返回值全部解析封装成 MapperMethod 对象，然后后面就可以开始准备执行 sql 语句了

执行 sql 语句

还是先来看一下执行 Sql 语句的时序图：

1、我们继续上面的流程进入 execute 方法：

2、这里面会根据语句类型以及返回值类型来决定如何执行，本人这里返回的是一个集合，故而我们进入 executeForMany 方法：

3、这里面首先会将前面存好的参数进行一次转换，然后绕了这么一圈，回到了起点 SqlSession 对象，继续调用 selectList 方法：

3、接下来又<typo id="typo-3735" data-origin="讲" ignoretag="true">讲</typo>流程委派给了 Execute 去执行 query 方法，最终又会去调用 queryFromDatabase 方法：

4、到这里之后，终于要进入正题了，一般带了这种 do 开头的方法就是真正做事的，Spring 中很多地方也是采用的这种命名方式：

注意，前面我们的 sql 语句还是占位符的方式，并没有将参数设置进去，所以这里在 return 上面一行调用 prepareStatement 方法创建 Statement 对象的时候会去设置参数，替换占位符。参数如何设置我们先跳过，等把流程执行完了我们<typo id="typo-3977" data-origin="在" ignoretag="true">在</typo>单独分析参数映射和结果集映射。

5、继续进入 PreparedStatementHandler 对象的 query 方法，可以看到，这一步就是调用了 jdbc 操作对象 PreparedStatement 中的 execute 方法，最后一步就是转换结果集然后返回。

到这里，整个 SQL 语句执行流程分析就结束了，中途有一些参数的存储以及转换并没有深入进去，因为参数的转换并不是核心，只要清楚整个数据的流转流程，我们自己也可以有自己的实现方式，只要存起来最后我们能重新解析读出来就行。

参数映射

现在我们来看一下上面在执行查询之前参数是如何进行设置的，我们先进入 prepareStatement 方法：

我们发现，最终是调用了 StatementHandler 中的 parameterize 进行参数设置，接下来这里为了节省篇幅，我们不会一步步点进去，直接进入设置参数的方法：

上面的 BaseTypeHandler 是一个抽象类，setNonNullParameter 并没有实现，都是交给子类去实现，而每一个子类就是对应了数据库的一种类型。下图中就是默认的一个子类 StringTypeHandler，里面没什么其他逻辑，就是设置参数。

可以看到 String 里面调用了 jdbc 中的 setString 方法，而如果是 int 也会调用 setInt 方法。这些子类就是系统默认提供的一些 typeHandler。而这些默认的 typeHandler 会默认被注册并和 Java 对象进行绑定：

正是因为 MyBatis 中默认提供了常用数据类型的映射，所以我们写 Sql 的时候才可以省略参数映射关系，可以直接采用下面的方式，系统可以根据我们参数的类型，自动选择合适的 typeHander 进行映射：

select user_id,user_name from lw_user where user_name=#{userName}

上面这条语句实际上和下面这条是等价的：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR}

或者说我们可以直接指定 typeHandler：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=org.apache.ibatis.type.IntegerTypeHandler}

这里因为我们配置了 typeHandler，所以会优先以配置的 typeHandler 为主不会再去读取默认的映射，如果类型不匹配就会直接报错了：

看到这里很多人应该就知道了，如果我们自己自定义一个 typeHandler，然后就可以配置成我们自己的自定义类。所以接下来就让我们看看如何自定义一个 typeHandler

自定义 typeHandler

自定义 typeHandler 需要实现 BaseTypeHandler 接口，BaseTypeHandler 有 4 个方法，包括结果集映射，为了节省篇幅，代码没有写上来：

package com.lonelyWolf.mybatis.typeHandler;

import org.apache.ibatis.type.BaseTypeHandler;import org.apache.ibatis.type.JdbcType;

import java.sql.CallableStatement;import java.sql.PreparedStatement;import java.sql.ResultSet;import java.sql.SQLException;

public class MyTypeHandler extends BaseTypeHandler<String> {

@Overridepublic void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {System.out.println("自定义 typeHandler 生效了");preparedStatement.setString(index,param);}

然后我们改写一下上面的查询语句：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}

然后执行，可以看到，自定义的 typeHandler 生效了：