前言

MyBatis可能很多人都一直在用，但是MyBatis的SQL執(zhí)行流程可能并不是所有人都清楚了，那么既然進來了，通讀本文你將收獲如下：

• 1、Mapper接口和映射文件是如何進行綁定的
• 2、MyBatis中SQL語句的執(zhí)行流程
• 3、自定義MyBatis中的參數(shù)設(shè)置處理器typeHandler
• 4、自定義MyBatis中結(jié)果集處理器typeHandler

PS：本文基于MyBatis3.5.5版本源碼。

概要

在MyBatis中，利用編程式進行數(shù)據(jù)查詢，主要就是下面幾行代碼：

SqlSession?session?=?sqlSessionFactory.openSession();
UserMapper?userMapper?=?session.getMapper(UserMapper.class);
List?userList?=?userMapper.listUserByUserName("孤狼1號");

第一行是獲取一個SqlSession對象在上一篇文章分析過了，想要詳細了解的可以點擊這里，第二行就是獲取UserMapper接口，第三行一行代碼就實現(xiàn)了整個查詢語句的流程，接下來我們就來仔細分析一下第二和第三步。

獲取Mapper接口(getMapper)

第二步是通過SqlSession對象是獲取一個Mapper接口，這個流程還是相對簡單的，下面就是我們調(diào)用session.getMapper方法之后的運行時序圖：

Mapper接口和映射文件是何時關(guān)聯(lián)的

Mapper接口及其映射文件是在加載mybatis-config配置文件的時候存儲進去的，下面就是時序圖：

但是這里有一個問題，如果有多重繼承或者多重依賴時在這里是可能會無法被完全解析的，比如說三個映射文件互相依賴，那么if里面(假設(shè)是最壞情況)只能加載1個，「失敗2個」，然后走到下面if之外的代碼又只能加載1個，「還有1個會失敗」(如下代碼中，只會處理1次，再次失敗并不會繼續(xù)加入incompleteResultMaps)：

「當(dāng)然，這個還是會被解析的，后面執(zhí)行查詢的時候會再次通過不斷遍歷去全部解析完畢，不過有一點需要注意的是，互相引用這種是會導(dǎo)致解析失敗報錯的，所以在開發(fā)過程中我們應(yīng)該避免循環(huán)依賴的產(chǎn)生」。

7、調(diào)用Configuration對象的addMapper

@Select("select?*?from?lw_user")
List?listAllUser();

所以這個方法里面會去解析@Select等注解，需要注意的是，「parse方法里面會同時再解析一次xml映射文件，因為上面我們提到了mappers節(jié)點有4種配置方式，其中兩種配置的是Mapper接口，而配置Mapper接口會直接先調(diào)用addMapper接口，并沒有解析映射文件，所以進入注解解析方法parse之中會需要再嘗試解析一次XML映射文件。」

解析完成之后，還會對Mapper接口中的方法進行解析，并將「每個方法的全限定類名作為key」存入存入Configuration中的mappedStatements屬性。

需要指出的是，這里存儲的時候，同一個value會存儲2次，「一個全限定名作為key，另一個就是只用方法名(sql語句的id)來作為key」：

所以最終mappedStatements會是下面的情況：

事實上如果我們通過接口的方式來編程的話，最后來getStatement的時候，都是根據(jù)全限定名來取的，「所以即使有重名對我們也沒有影響，而之所以要這么做的原因其實還是為了兼容早期版本的用法，那就是不通過接口，而是直接通過方法名的方式來進行查詢」：

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

這里如果shortName沒有重復(fù)的話，是可以直接通過簡寫來查詢的：

session.selectList("listAllUser");

但是通過簡寫來查詢一旦shortName重復(fù)了就會拋出以下異常：

這里的異常其實就是StrickMap的get方法拋出來的：

sql執(zhí)行流程分析

上面我們講到了，獲取到的Mapper接口實際上被包裝成為了代理對象，所以我們執(zhí)行查詢語句肯定是執(zhí)行的代理對象方法，接下來我們就以Mapper接口的代理對象MapperProxy來分析一下查詢流程。

整個sql執(zhí)行流程可以分為兩大步驟：

• 一、尋找sql
• 二、執(zhí)行sql語句

尋找sql

首先還是來看一下尋找sql語句的時序圖：

這里面就會把要執(zhí)行的sql語句，請求參數(shù)，方法返回值全部解析封裝成MapperMethod對象，然后后面就可以開始準備執(zhí)行sql語句了。想獲取Mybatis 系列面試題，可以關(guān)注公眾號Java技術(shù)棧回復(fù)面試，即可獲取。

執(zhí)行sql語句

還是先來看一下執(zhí)行Sql語句的時序圖：

1、我們繼續(xù)上面的流程進入execute方法：

2、這里面會根據(jù)語句類型以及返回值類型來決定如何執(zhí)行，本人這里返回的是一個集合，故而我們進入executeForMany方法：

3、這里面首先會將前面存好的參數(shù)進行一次轉(zhuǎn)換，然后繞了這么一圈，回到了起點SqlSession對象，繼續(xù)調(diào)用selectList方法：

4、接下來又講流程委派給了Execute去執(zhí)行query方法，最終又會去調(diào)用queryFromDatabase方法：

5、到這里之后，終于要進入正題了，一般帶了這種do開頭的方法就是真正做事的，Spring中很多地方也是采用的這種命名方式：

注意，前面我們的sql語句還是占位符的方式，并沒有將參數(shù)設(shè)置進去，所以這里在return上面一行調(diào)用prepareStatement方法創(chuàng)建Statement對象的時候會去設(shè)置參數(shù)，替換占位符。參數(shù)如何設(shè)置我們先跳過，等把流程執(zhí)行完了我們在單獨分析參數(shù)映射和結(jié)果集映射。

6、繼續(xù)進入PreparedStatementHandler對象的query方法，可以看到，這一步就是調(diào)用了jdbc操作對象PreparedStatement中的execute方法，最后一步就是轉(zhuǎn)換結(jié)果集然后返回。

到這里，整個SQL語句執(zhí)行流程分析就結(jié)束了，中途有一些參數(shù)的存儲以及轉(zhuǎn)換并沒有深入進去，因為參數(shù)的轉(zhuǎn)換并不是核心，只要清楚整個數(shù)據(jù)的流轉(zhuǎn)流程，我們自己也可以有自己的實現(xiàn)方式，只要存起來最后我們能重新解析讀出來就行。

參數(shù)映射

現(xiàn)在我們來看一下上面在執(zhí)行查詢之前參數(shù)是如何進行設(shè)置的，我們先進入prepareStatement方法：

我們發(fā)現(xiàn)，最終是調(diào)用了StatementHandler中的parameterize進行參數(shù)設(shè)置，接下來這里為了節(jié)省篇幅，我們不會一步步點進去，直接進入設(shè)置參數(shù)的方法：

上面的BaseTypeHandler是一個抽象類，setNonNullParameter并沒有實現(xiàn)，都是交給子類去實現(xiàn)，而每一個子類就是對應(yīng)了數(shù)據(jù)庫的一種類型。

推薦閱讀：Mybatis傳遞多個參數(shù)的4種方式。

下圖中就是默認的一個子類StringTypeHandler，里面沒什么其他邏輯，就是設(shè)置參數(shù)。

可以看到String里面調(diào)用了jdbc中的setString方法，而如果是int也會調(diào)用setInt方法。

看到這些子類如果大家之前閱讀過我前面講的MyBatis參數(shù)配置（關(guān)注Java技術(shù)棧搜索mybatis進行閱讀）應(yīng)該就很明顯可以知道，這些子類就是系統(tǒng)默認提供的一些typeHandler。而這些默認的typeHandler會默認被注冊并和Java對象進行綁定：

正是因為MyBatis中默認提供了常用數(shù)據(jù)類型的映射，所以我們寫Sql的時候才可以省略參數(shù)映射關(guān)系，可以直接采用下面的方式，系統(tǒng)可以根據(jù)我們參數(shù)的類型，自動選擇合適的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，所以會「優(yōu)先以配置的typeHandler為主」不會再去讀取默認的映射，如果類型不匹配就會直接報錯了：

看到這里很多人應(yīng)該就知道了，如果我們自己自定義一個typeHandler，然后就可以配置成我們自己的自定義類。所以接下來就讓我們看看如何自定義一個typeHandler

自定義typeHandler

自定義typeHandler需要實現(xiàn)BaseTypeHandler接口，BaseTypeHandler有4個方法，包括結(jié)果集映射，為了節(jié)省篇幅，代碼沒有寫上來：

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);
????}

然后我們改寫一下上面的查詢語句：

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

然后執(zhí)行，可以看到，自定義的typeHandler生效了：

結(jié)果集映射

接下來讓我們看看結(jié)果集的映射，回到上面執(zhí)行sql流程的最后一個方法：

resultSetHandler.handleResultSets(ps)

結(jié)果集映射里面的邏輯相對來說還是挺復(fù)雜的，因為要考慮到非常多的情況，這里我們就不會去深究每一個細節(jié)，直接進入到正式解析結(jié)果集的代碼，下面的5個代碼片段就是一個簡單的但是完整的解析流程：

從上面的代碼片段我們也可以看到，實際上解析結(jié)果集還是很復(fù)雜的，就如我們上一篇介紹的復(fù)雜查詢一樣，一個查詢可以不斷嵌套其他查詢，還有延遲加載等等一些復(fù)雜的特性 的處理，所以邏輯分支是有很多，但是不管怎么處理，最后的核心還是上面的一套流程，最終還是會調(diào)用typeHandler來獲取查詢到的結(jié)果。

是的，你沒猜錯，這個就是上面我們映射參數(shù)的typeHandler，因為typeHandler里面不只是一個設(shè)置參數(shù)方法，還有獲取結(jié)果集方法(上面設(shè)置參數(shù)的時候省略了)。

自定義typeHandler結(jié)果集

所以說我們還是用上面那個MyTypeHandler 例子來重寫一下取值方法(省略了設(shè)置參數(shù)方法)：

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>?{

????/**
?????*?設(shè)置參數(shù)
?????*/
????@Override
????public?void?setNonNullParameter(PreparedStatement?preparedStatement,?int?index,?String?param,?JdbcType?jdbcType)?throws?SQLException?{
????????System.out.println("設(shè)置參數(shù)->自定義typeHandler生效了");
????????preparedStatement.setString(index,param);
????}
????/**
?????*?根據(jù)列名獲取結(jié)果
?????*/
????@Override
????public?String?getNullableResult(ResultSet?resultSet,?String?columnName)?throws?SQLException?{
????????System.out.println("根據(jù)columnName獲取結(jié)果->自定義typeHandler生效了");
????????return?resultSet.getString(columnName);
????}

????/**
?????*?根據(jù)列的下標來獲取結(jié)果
?????*/
????@Override
????public?String?getNullableResult(ResultSet?resultSet,?int?columnIndex)?throws?SQLException?{
????????System.out.println("根據(jù)columnIndex獲取結(jié)果->自定義typeHandler生效了");
????????return?resultSet.getString(columnIndex);
????}

????/**
?????*?處理存儲過程的結(jié)果集
?????*/
????@Override
????public?String?getNullableResult(CallableStatement?callableStatement,?int?columnIndex)?throws?SQLException?{
????????return?callableStatement.getString(columnIndex);
????}
}

改寫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>

執(zhí)行之后輸出如下：

因為我們屬性上面只配置了一個屬性，所以只輸出了一次。

工作流程圖

上面介紹了代碼的流轉(zhuǎn)，可能繞來繞去有點暈，所以我們來畫一個主要的對象之間流程圖來更加清晰的展示一下MyBatis主要工作流程：

從上面的工作流程圖上我們可以看到，SqlSession下面還有4大對象，這4大對象也很重要，后面學(xué)習(xí)攔截器的時候就是針對這4大對象進行的攔截，關(guān)于這4大對象的具體詳情，我們下一篇文章再展開分析。

總結(jié)

本文主要分析了MyBatis的SQL執(zhí)行流程。在分析流程的過程中，我們也舉例論證了如何自定義typeHandler來實現(xiàn)自定義的參數(shù)映射和結(jié)果集映射，不過MyBatis中提供的默認映射其實可以滿足大部分的需求，如果我們對某些屬性需要特殊處理，那么就可以采用自定義的typeHandle來實現(xiàn)，相信如果本文如果讀懂了，以下幾點大家應(yīng)該至少會有一個清晰的認識：

• 1、Mapper接口和映射文件是如何進行綁定的
• 2、MyBatis中SQL語句的執(zhí)行流程
• 3、自定義MyBatis中的參數(shù)設(shè)置處理器typeHandler
• 4、自定義MyBatis中結(jié)果集處理器typeHandler

當(dāng)然，其中很多細節(jié)并沒有提到，而看源碼我們也并不需要追求每一行代碼都能看懂，就比如我們一個稍微復(fù)雜一點的業(yè)務(wù)系統(tǒng)，即使我們是項目開發(fā)者如果某一個模塊不是本人負責(zé)的，恐怕也很難搞清楚每一行代碼的含義。所以對于MyBatis及其他框架的源碼中也是一樣，首先應(yīng)該從大局入手，掌握整體流程和設(shè)計思想，然后如果對某些實現(xiàn)細節(jié)感興趣，再深入進行了解。

版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明。本文鏈接：https://blog.csdn.net/zwx900102/article/details/108455514

戳原文，獲取精選面試題！