【MyBatis系列6】想要學會MyBatis，看完這一篇就夠了

MyBatis的SQL執行流程分析

• 前言
• 概要
• 擷取Mapper接口(getMapper)
• • Mapper接口和映射檔案是何時關聯的
• sql執行流程分析
• • 尋找sql
  • 執行sql語句
• 參數映射
• • 自定義typeHandler
• 結果集映射
• • 自定義typeHandler結果集
• 工作流程圖
• 總結

前言

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号");
           

第一行是擷取一個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();
           

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

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

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

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

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

這裡如果shortName沒有重複的話，是可以直接通過簡寫來查詢的：

但是通過簡寫來查詢一旦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進行映射：

上面這條語句實際上和下面這條是等價的：

或者說我們可以直接指定typeHandler：

這裡因為我們配置了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);
    }
           

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

然後執行，可以看到，自定義的typeHandler生效了：

結果集映射

接下來讓我們看看結果集的映射，回到上面執行sql流程的最後一個方法：

結果集映射裡面的邏輯相對來說還是挺複雜的，因為要考慮到非常多的情況，這裡我們就不會去深究每一個細節，直接進入到正式解析結果集的代碼，下面的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);
    }
}
           

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

執行之後輸出如下：

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

工作流程圖

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

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

總結

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

• 1、Mapper接口和映射檔案是如何進行綁定的
• 2、MyBatis中SQL語句的執行流程
• 3、自定義MyBatis中的參數設定處理器typeHandler
• 4、自定義MyBatis中結果集處理器typeHandler

當然，其中很多細節并沒有提到，而看源碼我們也并不需要追求每一行代碼都能看懂，就比如我們一個稍微複雜一點的業務系統，即使我們是項目開發者如果某一個子產品不是本人負責的，恐怕也很難搞清楚每一行代碼的含義。是以對于MyBatis及其他架構的源碼中也是一樣，首先應該從大局入手，掌握整體流程和設計思想，然後如果對某些實作細節感興趣，再深入進行了解。

請關注我，和孤狼一起學習進步。