前言
MyBatis可能很多人都一直在用，但是MyBatis的SQL執行流程可能并不是所有人都清楚了，那麼既然進來了，通讀本文你将收獲如下：
1、Mapper接口和映射檔案是如何進行綁定的
2、MyBatis中SQL語句的執行流程
3、自定義MyBatis中的參數設定處理器typeHandler
4、自定義MyBatis中結果集處理器typeHandler
PS：本文基于MyBatis3.5.5版本源碼
幹貨分享最近将個人學習筆記整理成冊，使用PDF分享主要包含了Java基礎，資料結構，jvm，多線程等等，由于篇幅有限，以下隻展示小部分面試題，
需要的朋友可以點一點領取：戳這裡即可領取。。。暗号：CSDN
概要
在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方法。
當然，這個還是會被解析的，後面執行查詢的時候會再次通過不斷周遊去全部解析完畢，不過有一點需要注意的是，互相引用這種是會導緻解析失敗報錯的，是以在開發過程中我們應該避免循環依賴的産生。
6、解析完映射檔案之後，調用自身方法bindMapperForNamespace，開始綁定Mapper接口和映射檔案：
7、調用Configuration對象的addMapper
8、調用Configuration對象的屬性MapperRegistry内的addMapper方法，這個方法就是正式将Mapper接口添加到knownMappers，是以上面getMapper可以直接擷取：
到這裡我們就完成了Mapper接口和xml映射檔案的綁定
9、注意上面紅框裡面的代碼，又調用了一次parse方法，這個parse方法主要是解析注解，比如下面的語句：
@Select(“select * from lw_user”)
List 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方法：
接下來又講流程委派給了Execute去執行query方法，最終又會去調用queryFromDatabase方法：
4、到這裡之後，終于要進入正題了，一般帶了這種do開頭的方法就是真正做事的，Spring中很多地方也是采用的這種命名方式：
注意，前面我們的sql語句還是占位符的方式，并沒有将參數設定進去，是以這裡在return上面一行調用prepareStatement方法建立Statement對象的時候會去設定參數，替換占位符。參數如何設定我們先跳過，等把流程執行完了我們在單獨分析參數映射和結果集映射。
5、繼續進入PreparedStatementHandler對象的query方法，可以看到，這一步就是調用了jdbc操作對象PreparedStatement中的execute方法，最後一步就是轉換結果集然後傳回。
到這裡，整個SQL語句執行流程分析就結束了，中途有一些參數的存儲以及轉換并沒有深入進去，因為參數的轉換并不是核心，隻要清楚整個資料的流轉流程，我們自己也可以有自己的實作方式，隻要存起來最後我們能重新解析讀出來就行。