共计 8757 个字符，预计需要花费 22 分钟才能阅读完成。
前言
MyBatis 可能很多人都始终在用，然而 MyBatis 的 SQL 执行流程可能并不是所有人都分明了，那么既然进来了，通读本文你将播种如下：
- 1、Mapper 接口和映射文件是如何进行绑定的
- 2、MyBatis 中 SQL 语句的执行流程
- 3、自定义 MyBatis 中的参数设置处理器 typeHandler
- 4、自定义 MyBatis 中后果集处理器 typeHandler
PS：本文基于 MyBatis3.5.5 版本源码
概要
在 MyBatis 中，利用编程式进行数据查问，次要就是上面几行代码：
SqlSession session = sqlSessionFactory.openSession();
UserMapper userMapper = session.getMapper(UserMapper.class);
List<LwUser> userList = userMapper.listUserByUserName("孤狼 1 号");
123第一行是获取一个 SqlSession 对象在上一篇文章剖析过了，想要具体理解的能够点击这里，第二行就是获取 UserMapper 接口，第三行一行代码就实现了整个查问语句的流程，接下来咱们就来仔细分析一下第二和第三步。
获取 Mapper 接口(getMapper)
第二步是通过 SqlSession 对象是获取一个 Mapper 接口，这个流程还是绝对简略的，上面就是咱们调用 session.getMapper 办法之后的运行时序图：
- 1、在调用 getMapper 之后，会去 Configuration 对象中获取 Mapper 对象，因为在我的项目启动的时候就会把 Mapper 接口加载并解析存储到 Configuration 对象
- 2、通过 Configuration 对象中的 MapperRegistry 对象属性，持续调用 getMapper 办法
- 3、依据 type 类型，从 MapperRegistry 对象中的 knownMappers 获取到以后类型对应的代理工厂类，而后通过代理工厂类生成对应 Mapper 的代理类
- 4、最终获取到咱们接口对应的代理类 MapperProxy 对象
而 MapperProxy 能够看到实现了 InvocationHandler，应用的就是 JDK 动静代理。
至此获取 Mapper 流程完结了，那么就有一个问题了 MapperRegistry 对象内的 HashMap 属性 knownMappers 中的数据是什么时候存进去的呢？
Mapper 接口和映射文件是何时关联的
Mapper 接口及其映射文件是在加载 mybatis-config 配置文件的时候存储进去的，上面就是时序图：
- 1、首先咱们会手动调用 SqlSessionFactoryBuilder 办法中的 build()办法：
- 2、而后会结构一个 XMLConfigBuilder 对象，并调用其 parse 办法：
- 3、而后会持续调用本人的 parseConfiguration 来解析配置文件，这外面就会别离去解析全局配置文件的顶级节点，其余的咱们先不看，咱们间接看最初解析 mappers 节点
- 4、持续调用本人的 mapperElement 来解析 mappers 文件（这个办法比拟长，为了不便截图残缺，所以把字体放大了 1 号），能够看到，这外面分了四种形式来解析 mappers 节点的配置，对应了 4 种 mapper 配置形式，而其中红框内的两种形式是间接配置的 xml 映射文件，蓝框内的两种形式是解析间接配置 Mapper 接口的形式，从这里也能够阐明， 不管配置哪种形式，最终 MyBatis 都会将 xml 映射文件和 Mapper 接口进行关联。
- 5、咱们先看第 2 种和第 3 中（间接配置 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();
12所以这个办法外面会去解析 @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");
1这里如果 shortName 没有反复的话，是能够间接通过简写来查问的：
session.selectList("listAllUser");
1然而通过简写来查问一旦 shortName 反复了就会抛出以下异样：
这里的异样其实就是 StrickMap 的 get 办法抛出来的：
sql 执行流程剖析
下面咱们讲到了，获取到的 Mapper 接口实际上被包装成为了代理对象，所以咱们执行查问语句必定是执行的代理对象办法，接下来咱们就以 Mapper 接口的代理对象 MapperProxy 来剖析一下查问流程。
整个 sql 执行流程能够分为两大步骤：
- 一、寻找 sql
- 二、执行 sql 语句
寻找 sql
首先还是来看一下寻找 sql 语句的时序图：
- 1、理解代理模式的应该都晓得，调用被代理对象的办法之后实际上执行的就是代理对象的 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、接下来又讲流程委派给了 Execute 去执行 query 办法，最终又会去调用 queryFromDatabase 办法：
- 4、到这里之后，终于要进入正题了，个别带了这种 do 结尾的办法就是真正做事的，Spring 中很多中央也是采纳的这种命名形式：
留神，后面咱们的 sql 语句还是占位符的形式，并没有将参数设置进去，所以这里在 return 下面一行调用 prepareStatement 办法创立 Statement 对象的时候会去设置参数，替换占位符。参数如何设置咱们先跳过，等把流程执行完了咱们在独自剖析参数映射和后果集映射。
5、持续进入 PreparedStatementHandler 对象的 query 办法，能够看到，这一步就是调用了 jdbc 操作对象 PreparedStatement 中的 execute 办法，最初一步就是转换后果集而后返回。
到这里，整个 SQL 语句执行流程剖析就完结了，中途有一些参数的存储以及转换并没有深刻进去，因为参数的转换并不是外围，只有分明整个数据的流转流程，咱们本人也能够有本人的实现形式，只有存起来最初咱们能从新解析读出来就行。
参数映射
当初咱们来看一下下面在执行查问之前参数是如何进行设置的，咱们先进入 prepareStatement 办法：
咱们发现，最终是调用了 StatementHandler 中的 parameterize 进行参数设置，接下来这里为了节俭篇幅，咱们不会一步步点进去，间接进入设置参数的办法：
下面的 BaseTypeHandler 是一个抽象类，setNonNullParameter 并没有实现，都是交给子类去实现，而每一个子类就是对应了数据库的一种类型。下图中就是默认的一个子类 StringTypeHandler，外面没什么其余逻辑，就是设置参数。
能够看到 String 外面调用了 jdbc 中的 setString 办法，而如果是 int 也会调用 setInt 办法。
看到这些子类如果大家之前浏览过我后面讲的 MyBatis 参数配置，应该就很显著能够晓得，这些子类就是零碎默认提供的一些 typeHandler。而这些默认的 typeHandler 会默认被注册并和 Java 对象进行绑定：
正是因为 MyBatis 中默认提供了罕用数据类型的映射，所以咱们写 Sql 的时候才能够省略参数映射关系，能够间接采纳上面的形式，零碎能够依据咱们参数的类型，主动抉择适合的 typeHander 进行映射：
select user_id,user_name from lw_user where user_name=#{userName}
1下面这条语句实际上和上面这条是等价的：
select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR}
1或者说咱们能够间接指定 typeHandler：
select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=org.apache.ibatis.type.IntegerTypeHandler}
1这里因为咱们配置了 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> {
@Override
public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {System.out.println("自定义 typeHandler 失效了");
preparedStatement.setString(index,param);
}
1234567891011121314151617而后咱们改写一下下面的查问语句：
select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}
1而后执行，能够看到，自定义的 typeHandler 失效了：
后果集映射
接下来让咱们看看后果集的映射，回到下面执行 sql 流程的最初一个办法：
resultSetHandler.handleResultSets(ps)
1后果集映射外面的逻辑相对来说还是挺简单的，因为要思考到十分多的状况，这里咱们就不会去深究每一个细节，间接进入到正式解析后果集的代码，上面的 5 个代码片段就是一个简略的然而残缺的解析流程：
从下面的代码片段咱们也能够看到，实际上解析后果集还是很简单的，就如咱们上一篇介绍的简单查问一样，一个查问能够一直嵌套其余查问，还有提早加载等等一些简单的个性
的解决，所以逻辑分支是有很多，然而不管怎么解决，最初的外围还是下面的一套流程，最终还是会调用 typeHandler 来获取查问到的后果。
是的，你没猜错，这个就是下面咱们映射参数的 typeHandler，因为 typeHandler 外面不只是一个设置参数办法，还有获取后果集办法(下面设置参数的时候省略了)。
自定义 typeHandler 后果集
所以说咱们还是用下面那个 MyTypeHandler 例子来重写一下取值办法(省略了设置参数办法)：
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> {
/**
* 设置参数
*/
@Override
public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {System.out.println("设置参数 -> 自定义 typeHandler 失效了");
preparedStatement.setString(index,param);
}
/**
* 依据列名获取后果
*/
@Override
public String getNullableResult(ResultSet resultSet, String columnName) throws SQLException {System.out.println("依据 columnName 获取后果 -> 自定义 typeHandler 失效了");
return resultSet.getString(columnName);
}
/**
* 依据列的下标来获取后果
*/
@Override
public String getNullableResult(ResultSet resultSet, int columnIndex) throws SQLException {System.out.println("依据 columnIndex 获取后果 -> 自定义 typeHandler 失效了");
return resultSet.getString(columnIndex);
}
/**
* 解决存储过程的后果集
*/
@Override
public String getNullableResult(CallableStatement callableStatement, int columnIndex) throws SQLException {return callableStatement.getString(columnIndex);
}
}
12345678910111213141516171819202122232425262728293031323334353637383940414243444546改写 Mapper 映射文件配置：
<resultMap id="MyUserResultMap" type="lwUser">
<result column="user_id" property="userId" jdbcType="VARCHAR" typeHandler="com.lonelyWolf.mybatis.typeHandler.MyTypeHandler" />
<result column="user_name" property="userName" jdbcType="VARCHAR" />
</resultMap>
<select id="listUserByUserName" parameterType="String" resultMap="MyUserResultMap">
select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}
</select>
12345678执行之后输入如下：
因为咱们属性下面只配置了一个属性，所以只输入了一次。
工作流程图
下面介绍了代码的流转，可能绕来绕去有点晕，所以咱们来画一个次要的对象之间流程图来更加清晰的展现一下 MyBatis 次要工作流程：
从下面的工作流程图上咱们能够看到，SqlSession 上面还有 4 大对象，这 4 大对象也很重要，前面学习拦截器的时候就是针对这 4 大对象进行的拦挡，对于这 4 大对象的具体详情，咱们下一篇文章再开展剖析。
总结
本文次要剖析了 MyBatis 的 SQL 执行流程。在剖析流程的过程中，咱们也举例论证了如何自定义 typeHandler 来实现自定义的参数映射和后果集映射，不过 MyBatis 中提供的默认映射其实能够满足大部分的需要，如果咱们对某些属性须要非凡解决，那么就能够采纳自定义的 typeHandle 来实现，置信如果本文如果读懂了，以下几点大家应该至多会有一个清晰的意识：
- 1、Mapper 接口和映射文件是如何进行绑定的
- 2、MyBatis 中 SQL 语句的执行流程
- 3、自定义 MyBatis 中的参数设置处理器 typeHandler
- 4、自定义 MyBatis 中后果集处理器 typeHandler
当然，其中很多细节并没有提到，而看源码咱们也并不需要谋求每一行代码都能看懂，就比方咱们一个略微简单一点的业务零碎，即便咱们是我的项目开发者如果某一个模块不是自己负责的，恐怕也很难搞分明每一行代码的含意。所以对于 MyBatis 及其他框架的源码中也是一样，首先应该从大局动手，把握整体流程和设计思维，而后如果对某些实现细节感兴趣，再深刻进行理解。
作者: 双子孤狼
起源：https://blog.csdn.net/zwx9001…
最初分享一套微服务电商我的项目教程（材料笔记 + 视频）：关注上面公众号获取面试 材料 + 我的项目实战材料（电商 / 聚合领取 /），相干文档参考：https://www.laopaojava.com/posts/38510.html