关于mybatis:面试官MyBatis的SQL执行流程说这么清楚网上抄的吧

前言

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