Mybatis如何执行Select语句,你真的知道吗?,深入理解linux内核架构第一章

  • 由于此篇文章是基于前两篇文章的基础之上,因此重复的内容不再详细赘述了。

撸起袖子就是干


  • 二话不说,先来一张流程图,Mybatis六剑客,如下:六剑客执行流程图

  • 上图中的这六剑客在前面两篇文章中已经介绍的非常清楚了,此处略过。为什么源码解析的每一篇文章中都要放一张这个流程图呢?因为Mybatis底层就是围绕着这六剑客展开的,我们需要从全局掌握Mybatis的源码究竟如何执行的。

测试环境搭建

  • 举个栗子:根据用户id查询用户信息,Mapper定义如下:

List selectList(@Param(“userIds”) List userIds)

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

;

  • 对应XML配置如下:

select * from user_info where status=1

and user_id in

#{item}

  • 单元测试如下:

@Test

void contextLoads() {

List userInfos = userMapper.selectList(Arrays.asList(“192”,“198”));

System.out.println(userInfos);

}

DEBUG走起

  • 具体在哪里打上断点,上篇文章已经讲过了,不再赘述了。

  • 由于SpringBoot与Mybatis整合之后,自动注入的是SqlSessionTemplate,因此代码执行到org.mybatis.spring.SqlSessionTemplate#selectList(java.lang.String, java.lang.Object),如图1

  • 从源码可以看到,实际调用的还是DefaultSqlSession中的selectList方法。如下图2

  • 「具体的逻辑如下」

  1. 根据Mapper方法的全类名从Mybatis的配置中获取到这条SQL的详细信息,比如paramterType,resultMap等等。

  2. 既然开启了二级缓存,肯定先要判断这条SQL是否缓存过,因此实际调用的是CachingExecutor这个缓存执行器。

  • DefaultSqlSession只是简单的获取SQL的详细配置,最终还是把任务交给了Executor(当然这里走的是二级缓存,因此交给了缓存执行器)。下面DEBUG走到CachingExecutor#query(MappedStatement, java.lang.Object, RowBounds,ResultHandler),源码如下图3

  • 上图中的query方法实际做了两件事,实际执行的查询还是其中重载的方法List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql),如下图4

  • 根据上图源码的分析,其实CachingExecutor执行的逻辑并不是很难,反倒很容易理解,「具体的逻辑如下」

  1. 如果开启了二级缓存,先根据cacheKey从二级缓存中查询,如果查询到了直接返回

  2. 如果未开启二级缓存,再执行BaseExecutor中的query方法从一级缓存中查询。

  3. 如果二级缓存中未查询到数据,再执行BaseExecutor中的query方法从一级缓存中查询。

  4. 将查询到的结果存入到二级缓存中。

  • BaseExecutor中的query方法无非就是从一级缓存中取数据,没查到再从数据库中取数据,一级缓存实际就是一个Map结构,这里不再细说,真正执行SQL从数据库中取数据的是SimpleExecutor中的public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql)方法,源码如下图5

  • 从上面的源码也是可以知道,在真正执行SQL之前,是要调用prepareStatement(handler, ms.getStatementLog())方法做一些参数的预处理的,其中涉及到了六大剑客的另外两位,分别是ParameterHandlerTypeHandler,源码如图6

  • 从上图可以知道设置SQL参数的真正方法是handler.parameterize(stmt),真正执行的是DefaultParameterHandler中的setParameters方法,由于篇幅较长,简单的说一下思路:

  1. 获取所有参数的映射

  2. 循环遍历,获取参数的值,使用对应的TypeHandler将其转换成相应类型的参数。

  3. 真正的设置参数的方法是TypeHandlersetParameter方法

  • 继续图6的逻辑,参数已经设置完了,此时就该执行SQL了,真正执行SQL的是PreparedStatementHandler中的<E> List<E> query(Statement statement, ResultHandler resultHandler)方法,源码如下图7
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值