9000文字+代碼詳細講解SQL執行流程（一）！乾貨到底！建議收藏！

本次更新一下SQL執行流程，本篇爲上集，喜歡的朋友們可以三連支持一下哦！這纔是博主更新的動力~

一、SQL 執⾏⼊口

在單獨使用 MyBatis 進行數據庫操作時，我們通常都會先調用 SqlSession 接口的
getMapper方法爲我們的Mapper接口生成實現類。然後就可以通過Mapper進行數據庫操作。
比如像下面這樣：

ArticleMapper articleMapper = session.getMapper(ArticleMapper.class);
Article article = articleMapper.findOne(1);

如果大家對 MyBatis 較爲了解，會知道 SqlSession 是通過 JDK 動態代理的方式爲接口
生成代理對象的。在調用接口方法時，相關調用會被代理邏輯攔截。在代理邏輯中可根據方
法名及方法歸屬接口獲取到當前方法對應的 SQL 以及其他一些信息，拿到這些信息即可進
行數據庫操作。
以上是一個簡版的 SQL 執行過程，省略了很多細節。下面我們先按照這個簡版的流程
進行分析，首先來看一下 Mapper 接口的代理對象創建過程。

1.1 爲 Mapper 接⼜創建代理對象

本節，我們從 DefaultSqlSession 的 getMapper 方法開始看起，如下：

// -☆- DefaultSqlSession
public <T> T getMapper(Class<T> type) {
   
   
return configuration.<T>getMapper(type, this);
}
// -☆- Configuration
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
   
   
return mapperRegistry.getMapper(type, sqlSession);
}
// -☆- MapperRegistry
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
   
   
// 從 knownMappers 中獲取與 type 對應的 MapperProxyFactory
final MapperProxyFactory<T> mapperProxyFactory = 
(MapperProxyFactory<T>) knownMappers.get(type);
if (mapperProxyFactory == null) {
   
   
throw new BindingException("……");
 }
try {
   
   
// 創建代理對象
return mapperProxyFactory.newInstance(sqlSession);
 } catch (Exception e) {
   
   
throw new BindingException("……");
 } }

如上，經過連續的調用，Mapper 接口代理對象的創建邏輯初現端倪。如果大家沒分析過
MyBatis配置文件的解析過程，那麼可能不知道knownMappers集合中的元素是何時存入的，
這 裏簡 單說 明一 下。MyBatis 在解析配置文件的節點的過程中，會調用MapperRegistry 的 addMapper 方法將 Class 到 MapperProxyFactory 對象的映射關係存入到knownMappers。具體的代碼就不分析了，大家可以閱讀我之前寫的文章，或者自行分析相關的代碼。
在獲取到 MapperProxyFactory 對象後，即可調用工廠方法爲 Mapper 接口生成代理對象
了。相關邏輯如下：

// -☆- MapperProxyFactory
public T newInstance(SqlSession sqlSession) {
   
   
// 創建 MapperProxy 對象，MapperProxy 實現了 InvocationHandler 接口，
// 代理邏輯封裝在此類中
final MapperProxy<T> mapperProxy =
new MapperProxy<T>(sqlSession, mapperInterface, methodCache);
return newInstance(mapperProxy);
}
protected T newInstance(MapperProxy<T> mapperProxy) {
   
   
// 通過 JDK 動態代理創建代理對象
return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), 
new Class[]{
   
   mapperInterface}, mapperProxy);
}

上面的代碼首先創建了一個 MapperProxy 對象，該對象實現了 InvocationHandler 接口。
然後將對象作爲參數傳給重載方法，並在重載方法中調用 JDK 動態代理接口爲 Mapper 生成
代理對象。代理對象已經創建完畢，下面就可以調用接口方法進行數據庫操作了。由於接口
方法會被代理邏輯攔截，所以下面我們把目光聚焦在代理邏輯上面，看看代理邏輯會做哪些
事情。

1.2 執⾏代理邏輯

Mapper 接口方法的代理邏輯首先會對攔截的方法進行一些檢測，以決定是否執行後續
的數據庫操作。對應的代碼如下：

public Object invoke(Object proxy, 
Method method, Object[] args) throws Throwable {
   
   
try {
   
   
// 如果方法是定義在 Object 類中的，則直接調用
if (Object.class.equals(method.getDeclaringClass())) {
   
   
return method.invoke(this, args);
/*
* 下面的代碼最早出現在 mybatis-3.4.2 版本中，用於支持 JDK 1.8 中的
* 新特性 - 默認方法。這段代碼的邏輯就不分析了，有興趣的同學可以
* 去 Github 上看一下相關的相關的討論（issue #709），鏈接如下：
* 
* https://github.com/mybatis/mybatis-3/issues/709
*/
 } else if (isDefaultMethod(method)) {
   
   
 return invokeDefaultMethod(proxy, method, args);
 }
 } catch (Throwable t) {
   
   
throw ExceptionUtil.unwrapThrowable(t);
 }
// 從緩存中獲取 MapperMethod 對象，若緩存未命中，則創建 MapperMethod 對象
final MapperMethod mapperMethod = cachedMapperMethod(method);
// 調用 execute 方法執行 SQL
return mapperMethod.execute(sqlSession, args);
}

如上，代理邏輯會首先檢測被攔截的方法是不是定義在 Object 中的，比如 equals、
hashCode 方法等。對於這類方法，直接執行即可。除此之外，MyBatis 從 3.4.2 版本開始，
對 JDK1.8 接口的默認方法提供了支持，具體就不分析了。完成相關檢測後，緊接着從緩存
中獲取或者創建 MapperMethod 對象，然後通過該對象中的 execute 方法執行 SQL。在分析execute 方法之前，我們先來看一下 MapperMethod 對象的創建過程。MapperMethod 的創建過程看似普通，但卻包含了一些重要的邏輯，所以不能忽視。

1. 創建 MapperMethod 對象

本節來分析一下 MapperMethod 的構造方法，看看它的構造方法中都包含了哪些邏
輯。如下：

public class MapperMethod {
   
   
private final SqlCommand command;
private final MethodSignature method;
public MapperMethod(Class<?> mapperInterface,
Method method, Configuration config) {
   
   
// 創建 SqlCommand 對象，該對象包含一些和 SQL 相關的信息
this.command = new SqlCommand(config, mapperInterface, method);
// 創建 MethodSignature 對象，由類名可知，該對象包含了被攔截方法的一些信息
this.method = new MethodSignature(config, mapperInterface, method);
 } }

MapperMethod 構造方法的邏輯很簡單，主要是創建 SqlCommand 和 MethodSignature 對
象。這兩個對象分別記錄了不同的信息，這些信息在後續的方法調用中都會被用到。下面我
們深入到這兩個類的構造方法中，探索它們的初始化邏輯。

• 創建 SqlCommand 對象

前面說了 SqlCommand 中保存了一些和 SQL 相關的信息，那具體有哪些信息呢？答案
在下面的代碼中。

public static class SqlCommand {
   
   
private final String name;
private final SqlCommandType type;
public SqlCommand(Configuration configuration, 
Class<?> mapperInterface, Method method) {
   
   
final String methodName = method.getName();
final Class<?> declaringClass = method.getDeclaringClass();
// 解析 MappedStatement
MappedStatement ms = resolveMappedStatement(
mapperInterface, methodName, declaringClass, configuration);
// 檢測當前方法是否有對應的 MappedStatement
if (ms == null) {
   
   
// 檢測當前方法是否有 @Flush 註解
if (method.getAnnotation(Flush.class) != null) {
   
   
// 設置 name 和 type 遍歷
name = null;
type = SqlCommandType.FLUSH;
 } else {
   
   
// 若 ms == null 且方法無 @Flush 註解，此時拋出異常。
// 這個異常比較常見，大家應該眼熟吧
throw new BindingException("……");
 }
 } else {
   
   
// 設置 name 和 type 變量
name = ms.getId();
type = ms.getSqlCommandType();
if (type == SqlCommandType.UNKNOWN) {
   
   
throw new BindingException("……");
 }
 }
 } }

SqlCommand 的構造方法主要用於初始化它的兩個成員變量。代碼不是很長，
邏輯也不難理解，就不多說了。繼續往下看。

• 創建 MethodSignature 對象

MethodSignature 即方法簽名，顧名思義，該類保存了一些和目標方法相關的信息。比如
目標方法的返回類型，目標方法的參數列表信息等。下面，我們來分析一下 MethodSignature
的構造方法。

public static class MethodSignature {
   
   
private final boolean returnsMany;
private final boolean returnsMap;
private final boolean returnsVoid;
private final boolean returnsCursor;
private final Class<?> returnType;
private final String mapKey;
private final Integer resultHandlerIndex;
private final Integer rowBoundsIndex;
private final ParamNameResolver paramNameResolver;
public MethodSignature(Configuration configuration, 
Class<?> mapperInterface, Method method) {
   
   
// 通過反射解析方法返回類型
Type resolvedReturnType = TypeParameterResolver
.resolveReturnType(method, mapperInterface);
if (resolvedReturnType instanceof Class<?>) {
   
   
this.returnType = (Class<?>) resolvedReturnType;
 } else if (resolvedReturnType instanceof ParameterizedType) {
   
   
this.returnType = (Class<?>) (
(ParameterizedType) resolvedReturnType).getRawType();
 } else {
   
   
this.returnType = method.getReturnType();
 }
// 檢測返回值類型是否是 void、集合或數組、Cursor、Map 等
this.returnsVoid = void.class.equals(this.returnType);
this.returnsMany = configuration.getObjectFactory()
.isCollection(this.returnType) || this.returnType.isArray();
this.returnsCursor = Cursor.class.equals(this.returnType);
// 解析 @MapKey 註解，獲取註解內容
this.mapKey = getMapKey(method);
this.returnsMap = this.mapKey != null;
// 獲取 RowBounds 參數在參數列表中的位置，如果參數列表中
// 包含多個 RowBounds 參數，此方法會拋出異常
this.rowBoundsIndex = getUniqueParamIndex(method, RowBounds.class);
// 獲取 ResultHandler 參數在參數列表中的位置
this.resultHandlerIndex =
getUniqueParamIndex(method, ResultHandler.class);
// 解析參數列表
this.paramNameResolver =
new ParamNameResolver(configuration, method);
 } }

上面的代碼用於檢測目標方法的返回類型，以及解析目標方法參數列表。其中，檢測返
回類型的目的是爲避免查詢方法返回錯誤的類型。比如我們要求接口方法返回一個對象，結
果卻返回了對象集合，這會導致類型轉換錯誤。關於返回值類型的解析過程先說到這，下面
分析參數列表的解析過程。

public class ParamNameResolver {
   
   
private static final String GENERIC_NAME_PREFIX = "param";
private final SortedMap<Integer, String> names;
public ParamNameResolver(Configuration config, Method method) {
   
   
// 獲取參數類型列表
final Class<?>[] paramTypes = method.getParameterTypes();
// 獲取參數註解
final Annotation[][] paramAnnotations =
method.getParameterAnnotations();
final SortedMap<Integer, String> map =
new TreeMap<Integer, String>();
int paramCount = paramAnnotations.length;
for (int paramIndex = 0; paramIndex < paramCount; paramIndex++) {
   
   
// 檢測當前的參數類型是否爲 RowBounds 或 ResultHandler
if (isSpecialParameter(paramTypes[paramIndex])) {
   
   
continue;
 }
String name = null;
for (Annotation annotation : paramAnnotations[paramIndex]) {
   
   
if (annotation instanceof Param) {
   
   
hasParamAnnotation = true;
// 獲取 @Param 註解內容
name = ((Param) annotation).value();
break;
 }
 }
// name 爲空，表明未給參數配置 @Param 註解
if (name == null) {
   
   
// 檢測是否設置了 useActualParamName 全局配置
if (config.isUseActualParamName()) {
   
   
// 通過反射獲取參數名稱。此種方式要求 JDK 版本爲 1.8+，
// 且要求編譯時加入 -parameters 參數，否則獲取到的參數名
// 仍然是 arg1, arg2, ..., argN
name = getActualParamName(method, paramIndex);
 }
if (name == null) {
   
   
/*
* 使用 map.size() 返回值作爲名稱，思考一下爲什麼不這樣寫：
* name = String.valueOf(paramIndex);
* 因爲如果參數列表中包含 RowBounds 或 ResultHandler，這兩個
* 參數會被忽略掉，這樣將導致名稱不連續。
*
* 比如參數列表 (int p1, int p2, RowBounds rb, int p3)
* - 期望得到名稱列表爲 ["0", "1", "2"]
* - 實際得到名稱列表爲 ["0", "1", "3"]
*/
name = String.valueOf(map.size());
 }
 }
// 存儲 paramIndex 到 name 的映射
map.put(paramIndex, name);
 }
names = Collections.unmodifiableSortedMap(map);
 } }

方法參數列表解析完畢後，可得到參數下標與參數名的映射關係，這些映射關係最終存
儲在 ParamNameResolver 的 names 成員變量中。這些映射關係將會在後面的代碼中被用到，大家留意一下。下面寫點代碼測試一下 ParamNameResolver 的解析邏輯。如下：

public class ParamNameResolverTest {
   
   
@Test
public void test() throws NoSuchMethodException, 
NoSuchFieldException, IllegalAccessException {
   
   
Configuration config = new Configuration();
config.setUseActualParamName(false);
Method method = ArticleMapper.class.getMethod("select",
Integer.class, String.class, RowBounds.class, Article.class);
ParamNameResolver resolver = new ParamNameResolver(config, method);
Field field = resolver.getClass().getDeclaredField("names");
field.setAccessible(true);
// 通過反射獲取 ParamNameResolver 私有成員變量 names
Object names = field.get(resolver);
System.out.println("names: " + names);
 }
 class ArticleMapper {
   
   
public void select(@Param("id") Integer id, 
@Param("author") String author, RowBounds rb, Article article) {
   
   }
 } }

測試結果如下

參數索引與名稱映射圖如下

到此，關於 MapperMethod 的初始化邏輯就分析完了，繼續往下分析。

2. 執⾏ execute ⽅法

前面已經分析了 MapperMethod 的初始化過程，現在 MapperMethod 創建好了。那麼，
接下來要做的事情是調用 MapperMethod 的 execute 方法，執行 SQL。代碼如下：

// -☆- MapperMethod
public Object execute(SqlSession sqlSession, Object[] args) {
   
   
Object result;
// 根據 SQL 類型執行相應的數據庫操作
switch (command.getType()) {
   
   
case INSERT: {
   
   
// 對用戶傳入的參數進行轉換，下同
Object param = method.convertArgsToSqlCommandParam(args);
// 執行插入操作，rowCountResult 方法用於處理返回值
result = rowCountResult(s
qlSession.insert(command.getName(), param));
break;
 }
case UPDATE: {
   
   
Object param = method.convertArgsToSqlCommandParam(args);
// 執行更新操作
result = rowCountResult(
sqlSession.update(command.getName(), param));
break;
 }
case DELETE: {
   
   
Object param = method.convertArgsToSqlCommandParam(args);
// 執行刪除操作
result = rowCountResult(
sqlSession.delete(command.getName(), param));
break;
 }
case SELECT:
// 根據目標方法的返回類型進行相應的查詢操作
if (method.returnsVoid() && method.hasResultHandler()) {
   
   
// 如果方法返回值爲 void，但參數列表中包含 ResultHandler，表明
// 使用者想通過 ResultHandler 的方式獲取查詢結果，而非通過返回值
// 獲取結果
executeWithResultHandler(sqlSession, args);
result = null;
} else if (method.returnsMany()) {
   
   
// 執行查詢操作，並返回多個結果
result = executeForMany(sqlSession, args);
 } else if (method.returnsMap()) {
   
   
// 執行查詢操作，並將結果封裝在 Map 中返回
result = executeForMap(sqlSession, args);
 } else if (method.returnsCursor()) {
   
   
// 執行查詢操作，並返回一個 Cursor 對象
result = executeForCursor(sqlSession, args);
 } else {
   
   
Object param = method.convertArgsToSqlCommandParam(args);
// 執行查詢操作，並返回一個結果
result = sqlSession.selectOne(command.getName(), param);
 }
break;
case FLUSH:
// 執行刷新操作
result = sqlSession.flushStatements();
break;
default:
throw new BindingException("……");
 }
// 如果方法的返回值爲基本類型，而返回值卻爲 null，此種情況下應拋出異常
if (result == null && method.getReturnType().isPrimitive() 
&& !method.returnsVoid()) {
   
   
throw new BindingException("……");
 }
return result; }

如上，execute 方法主要由一個 switch 語句組成，用於根據 SQL 類型執行相應的數據庫
操作。該方法的邏輯清晰，不需 要太多的分析。不過在上面 代 碼 中convertArgsToSqlCommandParam 方法出現次數比較頻繁，這裏分析一下：

// -☆- MapperMethod
public Object convertArgsToSqlCommandParam(Object[] args) {
   
   
return paramNameResolver.getNamedParams(args);
}
public Object getNamedParams(Object[] args) {
   
   
final int paramCount = names.size();
if (args == null || paramCount == 0) {
   
   
return null;
 } else if (!hasParamAnnotation && paramCount == 1) {
   
   
/*
* 如果方法參數列表無 @Param 註解，且僅有一個非特別參數，則返回該
* 參數的值。比如如下方法：
* List findList(RowBounds rb, String name)
* names 如下：
* names = {1 : "0"}
* 此種情況下，返回 args[names.firstKey()]，即 args[1] -> name
*/
return args[names.firstKey()];
 } else {
   
   
final Map<String, Object> param = new ParamMap<Object>();
int i = 0;
for (Map.Entry<Integer, String> entry : names.entrySet()) {
   
   
// 添加 <參數名, 參數值> 鍵值對到 param 中
param.put(entry.getValue(), args[entry.getKey()]);
// genericParamName = param + index。比如 param1, param2,... paramN
final String genericParamName =
GENERIC_NAME_PREFIX + String.valueOf(i + 1);
// 檢測 names 中是否包含 genericParamName，什麼情況下會包含？
// 答案如下：
// 使用者顯式將參數名稱配置爲 param1，即 @Param("param1")
if (!names.containsValue(genericParamName)) {
   
   
// 添加 <param*, value> 到 param 中
param.put(genericParamName, args[entry.getKey()]);
 }i++;
 }
 return param;
 } }

convertArgsToSqlCommandParam 是一個空殼方法，該方法最終調用了
ParamNameResolver 的 getNamedParams 方法。getNamedParams 方法的主要邏輯是根據條件返回不同的結果，該方法的代碼不是很難理解，我也進行了比較詳細的註釋，就不多說了。
分析完 convertArgsToSqlCommandParam 的邏輯，接下來說說 MyBatis 對哪些 SQL 指令提供了支持，如下：

• 查詢語句：SELECT
• 更新語句：INSERT/UPDATE/DELETE
• 存儲過程：CALL

在上面的列表中，我刻意對 SELECT/INSERT/UPDATE/DELETE 等指令進行了分類，分
類依據指令的功能以及 MyBatis 執行這些指令的過程。這裏把 SELECT 稱爲查詢語句，
INSERT/UPDATE/DELETE 等稱爲更新語句。下來按照順序對着兩種語句執行過程進行分析，
先來分析查詢語句的執行過程。

二、 查詢語句的執⾏過程

查詢語句對應的方法比較多，有如下幾種：

• executeWithResultHandler
• executeForMany
• executeForMap
• executeForCursor

這些方法在內部調用了 SqlSession 中的一些 select方法，比如 selectList、selectMap、
selectCursor 等。這些方法的返回值類型是不同的，因此對於每種返回類型，需要有專門的處理方法。以 selectList 方法爲例，該方法的返回值類型爲 List。但如果我們的 Mapper 或 Dao的接口方法返回值類型爲數組，或者 Set，直接將 List 類型的結果返回給 Mapper/Dao 就不合適了。execute
等方法只是對 select等方法做了一層簡單的封裝，因此接下來我們應們應該把目光放在這些 select方法上。

2.1 selectOne ⽅法分析

本節選擇分析 selectOne 方法，而不是其他的方法，大家或許會覺得奇怪。前面提及了
selectList、selectMap、selectCursor 等方法，這裏卻分析一個未提及的方法。這樣做並沒什麼
特別之處，主要原因是 selectOne 在內部會調用 selectList 方法。這裏分析 selectOne 方法是
爲了告知大家，selectOne 和 selectList 方法是有聯繫的，同時分析 selectOne 方法等同於分析
selectList 方法。如果你不信的話，那我們看源碼吧，源碼面前了無祕密。

// -☆- DefaultSqlSession
public <T> T selectOne(String statement, Object parameter) {
   
   
// 調用 selectList 獲取結果
List<T> list = this.<T>selectList(statement, parameter);
if (list.size() == 1) {
   
   
// 返回結果
return list.get(0);
 } else if (list.size() > 1) {
   
   
// 如果查詢結果大於 1 則拋出異常，這個異常也是很常見的
throw new TooManyResultsException("……");
 } else {
   
   
return null;
 } }

如上，selectOne 方法在內部調用 selectList 了方法，並取 selectList 返回值的第 1 個元素
作爲自己的返回值。如果 selectList 返回的列表元素大於 1，則拋出異常。上面代碼比較易懂，就不多說了。下面我們來看看 selectList 方法的實現。

// -☆- DefaultSqlSession
public <E> List<E> selectList(String statement, Object parameter) {
   
   
// 調用重載方法
return this.selectList(statement, parameter, RowBounds.DEFAULT);
}
private final Executor executor;
public <E> List<E> selectList(String statement, Object parameter, RowBounds
rowBounds) {
   
   
try {
   
   
// 獲取 MappedStatement
MappedStatement ms = configuration.getMappedStatement(statement);
// 調用 Executor 實現類中的 query 方法
return executor.query(ms, wrapCollection(parameter), 
rowBounds, Executor.NO_RESULT_HANDLER);
 } catch (Exception e) {
   
   
throw ExceptionFactory.wrapException("……");
 } finally {
   
   
ErrorContext.instance().reset();
 } }

如上，這裏要來說說 executor 變量，該變量類型爲 Executor。Executor 是一個接口，它
的實現類如下：

Executor 有這麼多的實現類，大家猜一下 executor 變量對應哪個實現類。要弄清楚這個
問題，需要大家到源頭去查證。這裏提示一下，大家可以跟蹤一下 DefaultSqlSessionFactory的openSession 方法，很快就能發現 executor 變量創建的蹤跡。限於篇幅原因，本文就不分析 openSession 方法的源碼了。默認情況下，executor 的類型爲 CachingExecutor，該類是一個裝飾器類，用於給目標 Executor 增加二級緩存功能。那目標 Executor 是誰呢？默認情況下是 SimpleExecutor。
現在大家搞清楚 executor 變量的身份了，接下來繼續分析 selectOne 方法的調用棧。先
來看看 CachingExecutor 的 query 方法是怎樣實現的。如下：

// -☆- CachingExecutor
public <E> List<E> query(MappedStatement ms, Object parameterObject, 
RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
   
   
// 獲取 BoundSql
BoundSql boundSql = ms.getBoundSql(parameterObject);
// 創建 CacheKey
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
// 調用重載方法
return query(ms, parameterObject, 
rowBounds, resultHandler, key, boundSql);
}

上面的代碼用於獲取 BoundSql 對象，創建 CacheKey 對象，然後再將這兩個對象傳給重
載方法。BoundSql 的獲取過程較爲複雜，我將在下一節進行分析。CacheKey 以及接下來即
將出現的一二級緩存將會獨立成章分析。上面的方法等代碼和 SimpleExecutor 父類 BaseExecutor 中的實現沒什麼區別，有區別的地方在於這個方法所調用的重載方法。繼續往下看。

// -☆- CachingExecutor
public <E> List<E> query(MappedStatement ms, Object parameterObject, 
RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, 
BoundSql boundSql) throws SQLException {
   
   
// 從 MappedStatement 中獲取緩存
Cache cache = ms.getCache();
// 若映射文件中未配置緩存或參照緩存，此時 cache = null
if (cache != null) {
   
   
flushCacheIfRequired(ms);
if (ms.isUseCache() && resultHandler == null) {
   
   
ensureNoOutParams(ms, boundSql);
List<E> list = (List<E>) tcm.getObject(cache, key);
if (list == null) {
   
   
// 若緩存未命中，則調用被裝飾類的 query 方法
list = delegate.<E>query(ms, parameterObject, 
rowBounds, resultHandler, key, boundSql);
tcm.putObject(cache, key, list); // issue #578 and #116
 }
return list;
 } }
// 調用被裝飾類的 query 方法
return delegate.<E>query(
ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

以上代碼涉及到了二級緩存，若二級緩存爲空，或未命中，則調用被裝飾類的 query 方
法。下面來看一下 BaseExecutor 的中籤名相同的 query 方法是如何實現的。

// -☆- BaseExecutor
public <E> List<E> query(MappedStatement ms, Object parameter, 
RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, 
BoundSql boundSql) throws SQLException {
   
   
if (closed) {
   
   
throw new ExecutorException("Executor was closed.");
}
if (queryStack == 0 && ms.isFlushCacheRequired()) {
   
   
clearLocalCache();
 }
List<E> list;
try {
   
   
queryStack++;
// 從一級緩存中獲取緩存項
list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
if (list != null) {
   
   
// 存儲過程相關處理邏輯，本文不分析存儲過程，故該方法不分析了
handleLocallyCachedOutputParameters(ms,key,parameter,boundSql);
 } else {
   
   
// 一級緩存未命中，則從數據庫中查詢
list = queryFromDatabase(ms, parameter, 
rowBounds, resultHandler, key, boundSql);
 }
 } finally {
   
   
queryStack--; }
if (queryStack == 0) {
   
   
// 從一級緩存中延遲加載嵌套查詢結果
for (DeferredLoad deferredLoad : deferredLoads) {
   
   
deferredLoad.load();
 }
deferredLoads.clear();
if (configuration.getLocalCacheScope()==LocalCacheScope.STATEMENT) {
   
   
clearLocalCache();
 }
 }
return list; }

上面的方法主要用於從一級緩存中查找查詢結果，若緩存未命中，再向數據庫進行查詢。
在上面的代碼中，出現了一個新的類 DeferredLoad，這個類用於延遲加載。該類的實現並不
複雜，但是具體用途讓我有點疑惑。這個我目前也未完全搞清楚，就不分析了。接下來，我
們來看一下 queryFromDatabase 方法的實現。

// -☆- BaseExecutor
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, 
RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, 
BoundSql boundSql) throws SQLException {
   
   
List<E> list;
// 向緩存中存儲一個佔位符
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
   
   
// 調用 doQuery 進行查詢
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
 } finally {
   
   
// 移除佔位符
localCache.removeObject(key);
 }
// 緩存查詢結果
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
   
   
localOutputParameterCache.putObject(key, parameter);
 }
return list; }

上面的代碼仍然不是 selectOne 方法調用棧的終點，拋開緩存操作，queryFromDatabase
最終還會調用 doQuery 進行查詢。所以下面我們繼續進行跟蹤。

// -☆- SimpleExecutor
public <E> List<E> doQuery(MappedStatement ms, Object parameter, 
RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) 
throws SQLException {
   
   
Statement stmt = null;
try {
   
   
Configuration configuration = ms.getConfiguration();
// 創建 StatementHandler
StatementHandler handler = configuration.newStatementHandler(
wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
// 創建 Statement
stmt = prepareStatement(handler, ms.getStatementLog());
// 執行查詢操作
return handler.<E>query(stmt, resultHandler);
 } finally {
   
   
// 關閉 Statement
closeStatement(stmt);
 } }

doQuery 方法中仍然有不少的邏輯，完全看不到即將要到達終點的趨勢，不過這離終點
又近了一步。接下來，我們先跳過 StatementHandler 和 Statement 創建過程，這兩個對象的創建過程會在後面進行說明。這裏，我們以 PreparedStatementHandler 爲例，看看它的 query 方法是怎樣實現的。如下：

// -☆- PreparedStatementHandler
public <E> List<E> query(Statement statement, ResultHandler resultHandler) 
throws SQLException {
   
   
PreparedStatement ps = (PreparedStatement) statement;
// 執行 SQL
ps.execute();
// 處理執行結果
return resultSetHandler.<E>handleResultSets(ps);
}

到這裏似乎看到了希望，整個調用過程總算要結束了。不過先別高興的太早，SQL 執行
結果的處理過程也很複雜，稍後將會專門拿出一節內容進行分析。
以上就是 selectOne 方法的執行過程，儘管我已經簡化了代碼分析，但是整個過程看起來還是很複雜的。查詢過程涉及到了很多方法調用，不把這些調用方法搞清楚，很難對
MyBatis 的查詢過程有深入的理解。所以在接下來的章節中，我將會對一些重要的調用進行
分析。如果大家不滿足於泛泛而談，那麼接下來咱們一起進行更深入的探索吧。

2.2 獲取 BoundSql

在執行 SQL 之前，需要將 SQL 語句完整的解析出來。我們都知道 SQL 是配置在映射文
件中的，但由於映射文件中的 SQL 可能會包含佔位符#{}，以及動態 SQL 標籤，比如、
等。因此，我們並不能直接使用映射文件中配置的 SQL。MyBatis 會將映射文件中
的 SQL 解析成一組 SQL 片段。如果某個片段中也包含動態 SQL 相關的標籤，那麼，MyBatis會對該片段再次進行分片。最終，一個 SQL 配置將會被解析成一個 SQL 片段樹。形如下面的圖片：

我們需要對片段樹進行解析，以便從每個片段對象中獲取相應的內容。然後將這些內容
組合起來即可得到一個完成的 SQL 語句，這個完整的 SQL 以及其他的一些信息最終會存儲
在 BoundSql 對象中。下面我們來看一下 BoundSql 類的成員變量信息，如下：

private final String sql;
private final List<ParameterMapping> parameterMappings;
private final Object parameterObject;
private final Map<String, Object> additionalParameters;
private final MetaObject metaParameters;

下面用一個表格列舉各個成員變量的含義

以上對 BoundSql 的成員變量做了簡要的說明，部分參數的用途大家現在可能不是很明
白。不過不用着急，這些變量在接下來的源碼分析過程中會陸續的出現。到時候對着源碼多
思考，或是寫點測試代碼調試一下，即可弄懂。
好了，現在準備工作已經做好。接下來，開始分析 BoundSql 的構建過程。我們源碼之
旅的第一站是 MappedStatement 的 getBoundSql 方法，代碼如下：

// -☆- MappedStatement
public BoundSql getBoundSql(Object parameterObject) {
   
   
// 調用 sqlSource 的 getBoundSql 獲取 BoundSql
BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
List<ParameterMapping> parameterMappings =
boundSql.getParameterMappings();
if (parameterMappings == null || parameterMappings.isEmpty()) {
   
   
// 創建新的 BoundSql，這裏的 parameterMap 是 ParameterMap 類型。
// 由<ParameterMap> 節點進行配置，該節點已經廢棄，不推薦使用。
// 默認情況下，parameterMap.getParameterMappings() 返回空集合
boundSql = new BoundSql(configuration, boundSql.getSql(), 
parameterMap.getParameterMappings(), parameterObject);
 }
// 省略不重要的邏輯
return boundSql; }

如上，MappedStatement 的 getBoundSql 在內部調用了 SqlSource 實現類的 getBoundSql
方法。處理此處的調用，餘下的邏輯都不是重要邏輯，就不囉嗦了。接下來，我們把目光轉
移到 SqlSource 實現類的 getBoundSql 方法上。SqlSource 是一個接口，它有如下幾個實現類：

• DynamicSqlSource
• RawSqlSource
• StaticSqlSource
• ProviderSqlSource
• VelocitySqlSource

在如上幾個實現類中，我們應該選擇分析哪個實現類的邏輯呢？首先我們把最後兩個排
除掉，不常用。剩下的三個實現類中，僅前兩個實現類會在映射文件解析的過程中被使用。
當 SQL 配置中包含${}（不是#{}）佔位符，或者包含、等標籤時，會被認爲是
動態 SQL，此時使用 DynamicSqlSource 存儲 SQL 片段。否則，使用 RawSqlSource 存儲 SQL配置信息。相比之下 DynamicSqlSource 存儲的 SQL 片段類型較多，解析起來也更爲複雜一些。因此下面我將分析 DynamicSqlSource 的 getBoundSql 方法。弄懂這個，RawSqlSource 也不在話下。

// -☆- DynamicSqlSource
public BoundSql getBoundSql(Object parameterObject) {
   
   
// 創建 DynamicContext
DynamicContext context =
new DynamicContext(configuration, parameterObject);
// 解析 SQL 片段，並將解析結果存儲到 DynamicContext 中
rootSqlNode.apply(context);
SqlSourceBuilder sqlSourceParser = new SqlSourceBuilder(configuration);
Class<?> parameterType = parameterObject == null ?
Object.class : parameterObject.getClass();
// 構建 StaticSqlSource，在此過程中將 sql 語句中的佔位符 #{} 替換爲問號 ?，
// 併爲每個佔位符構建相應的 ParameterMapping
SqlSource sqlSource = sqlSourceParser.parse(
context.getSql(), parameterType, context.getBindings());
// 調用 StaticSqlSource 的 getBoundSql 獲取 BoundSql
BoundSql boundSql = sqlSource.getBoundSql(parameterObject);
// 將 DynamicContext 的 ContextMap 中的內容拷貝到 BoundSql 中
for(Map.Entry<String, Object> entry : context.getBindings().entrySet()){
   
   
boundSql.setAdditionalParameter(entry.getKey(), entry.getValue());
 }
return boundSql; }

如上，DynamicSqlSource 的 getBoundSql 方法的代碼看起來不多，但是邏輯卻並不簡單。
該方法由數個步驟組成，這裏總結一下：

1. 創建 DynamicContext
2. 解析 SQL 片段，並將解析結果存儲到 DynamicContext 中
3. 解析 SQL 語句，並構建 StaticSqlSource
4. 調用 StaticSqlSource 的 getBoundSql 獲取 BoundSql
5. 將 DynamicContext 的 ContextMap 中的內容拷貝到 BoundSql 中

如上 5 個步驟中，第 5 步爲常規操作，就不多說了，其他步驟將會在接下來章節中一一
進行分析。按照順序，我們先來分析 DynamicContext 的實現。

1．DynamicContext

DynamicContext 是 SQL 語句構建的上下文，每個 SQL 片段解析完成後，都會將解析結
果存入 DynamicContext 中。待所有的 SQL 片段解析完畢後，一條完整的 SQL 語句就會出現在 DynamicContext 對象中。下面我們來看一下 DynamicContext 類的定義。

public class DynamicContext {
   
   
public static final String PARAMETER_OBJECT_KEY = "_parameter";
public static final String DATABASE_ID_KEY = "_databaseId";
private final ContextMap bindings;
private final StringBuilder sqlBuilder = new StringBuilder();
public DynamicContext(
Configuration configuration, Object parameterObject) {
   
   
// 創建 ContextMap
if (parameterObject != null && !(parameterObject instanceof Map)) {
   
   
MetaObject metaObject =
configuration.newMetaObject(parameterObject);
bindings = new ContextMap(metaObject);
 } else {
   
   
bindings = new ContextMap(null);
 }
// 存放運行時參數 parameterObject 以及 databaseId
bindings.put(PARAMETER_OBJECT_KEY, parameterObject);
bindings.put(DATABASE_ID_KEY, configuration.getDatabaseId());
 } }

上面只貼了 DynamicContext 類的部分代碼。其中 sqlBuilder 變量用於存放 SQL 片段的
解析結果，bindings 則用於存儲一些額外的信息，比如運行時參數和 databaseId 等。bindings類型爲 ContextMap，ContextMap 定義在 DynamicContext 中，是一個靜態內部類。該類繼承自 HashMap，並覆寫了 get 方法。它的代碼如下：

static class ContextMap extends HashMap<String, Object> {
   
   
private MetaObject parameterMetaObject;
public ContextMap(MetaObject parameterMetaObject) {
   
   
this.parameterMetaObject = parameterMetaObject;
 }
@Override
public Object get(Object key) {
   
   
String strKey = (String) key;
// 檢查是否包含 strKey，若包含則直接返回
if (super.containsKey(strKey)) {
   
   
return super.get(strKey);
 }
if (parameterMetaObject != null) {
   
   
// 從運行時參數中查找結果
return parameterMetaObject.getValue(strKey);
 }
return null;
 } }

DynamicContext 對外提供了兩個接口，用於操作 sqlBuilder。分別如下：

public void appendSql(String sql) {
   
   
sqlBuilder.append(sql);
sqlBuilder.append(" ");
}
public String getSql() {
   
   
return sqlBuilder.toString().trim();
}

以上就是對 DynamicContext 的簡單介紹，DynamicContext 的源碼不難理解，這裏就不
多說了。繼續往下分析。

2. 解析 SQL ⽚段

對於一個包含了${}佔位符，或<if>、<where>等標籤的 SQL，在解析的過程中，會被分解
成多個片段。每個片段都有對應的類型，每種類型的片段都有不同的解析邏輯。在源碼中，
片段這個概念等價於 sql 節點，即 SqlNode。SqlNode 是一個接口，它有衆多的實現類。其繼
承體系如下：

上圖只畫出了部分的實現類，還有一小部分沒畫出來，不過這並不影響接下來的分析。
在衆多實現類中，StaticTextSqlNode 用於存儲靜態文本，TextSqlNode 用於存儲帶有${}佔位符的文本，IfSqlNode 則用於存儲節點的內容。MixedSqlNode 內部維護了一個 SqlNode
集合，用於存儲各種各樣的 SqlNode。接下來，我將會對 MixedSqlNode、StaticTextSqlNode、TextSqlNode、IfSqlNode、WhereSqlNode 以及 TrimSqlNode 等進行分析，其他的實現類請大家自行分析。

public class MixedSqlNode implements SqlNode {
   
   
private final List<SqlNode> contents;
public MixedSqlNode(List<SqlNode> contents) {
   
   
this.contents = contents;
 }
 @Override
public boolean apply(DynamicContext context) {
   
   
// 遍歷 SqlNode 集合
for (SqlNode sqlNode : contents) {
   
   
// 調用 salNode 對象本身的 apply 方法解析 sql
sqlNode.apply(context);
 }
return true;
 } }

MixedSqlNode 可以看做是 SqlNode 實現類對象的容器，凡是實現了 SqlNode 接口的類
都可以存儲到 MixedSqlNode 中，包括它自己。MixedSqlNode 解析方法 apply 邏輯比較簡單，即遍歷 SqlNode 集合，並調用其他 SalNode 實現類對象的 apply 方法解析 sql。那下面我們來看看其他 SalNode 實現類的 apply 方法是怎樣實現的。

public class StaticTextSqlNode implements SqlNode {
   
   
private final String text;
public StaticTextSqlNode(String text) {
   
   
this.text = text;
 }
@Override
public boolean apply(DynamicContext context) {
   
   
context.appendSql(text);
return true;
 } }

StaticTextSqlNode 用於存儲靜態文本，所以它不需要什麼解析邏輯，直接將其存儲的
SQL 片段添加到 DynamicContext 中即可。StaticTextSqlNode 的實現比較簡單，看起來很輕
松。下面分析一下 TextSqlNode。

public class TextSqlNode implements SqlNode {
   
   
private final String text;
private final Pattern injectionFilter;
@Override
public boolean apply(DynamicContext context) {
   
   
// 創建 ${} 佔位符解析器
GenericTokenParser parser = createParser(
new BindingTokenParser(context, injectionFilter));
// 解析 ${} 佔位符，並將解析結果添加到 DynamicContext 中
context.appendSql(parser.parse(text));
return true;
 }
private GenericTokenParser createParser(TokenHandler handler) {
   
   
// 創建佔位符解析器，GenericTokenParser 是一個通用解析器，
// 並非只能解析 ${} 佔位符
return new GenericTokenParser("${", "}", handler);
 }
private static class BindingTokenParser implements TokenHandler {
   
   
private DynamicContext context;
private Pattern injectionFilter;
public BindingTokenParser(
DynamicContext context, Pattern injectionFilter) {
   
   
this.context = context;
this.injectionFilter = injectionFilter;
 }
@Override
public String handleToken(String content) {
   
   
Object parameter = context.getBindings().get("_parameter");
if (parameter == null) {
   
   
context.getBindings().put("value", null);
 }else if(SimpleTypeRegistry.isSimpleType(parameter.getClass())){
   
   
context.getBindings().put("value", parameter);
 }
// 通過 ONGL 從用戶傳入的參數中獲取結果
Object value = OgnlCache
.getValue(content, context.getBindings());
String srtValue = (value == null ? "" : String.valueOf(value));
// 通過正則表達式檢測 srtValue 有效性
checkInjection(srtValue);
return srtValue;
 }
 } }

如上，GenericTokenParser 是一個通用的標記解析器，用於解析形如KaTeX parse error: Expected 'EOF', got '#' at position 7: {xxx}，#̲{xxx}等標 記 。Gene…{xxx}標記。舉個例子說明一下吧，如下。我們有這樣一個 SQL 語句，用於從 article 表中查詢某個作者所寫的文章。如下：
SELECT * FROM article WHERE author = '${author}'
假設我們我們傳入的 author 值爲 tianxiaobo，那麼該 SQL 最終會被解析成如下的結果：
SELECT * FROM article WHERE author = 'tianxiaobo'
一般情況下，使用${author}接受參數都沒什麼問題。但是怕就怕在有人不懷好意，構建
了一些惡意的參數。當用這些惡意的參數替換${author}時就會出現災難性問題——SQL 注
入。比如我們構建這樣一個參數 author=tianxiaobo’;DELETE FROM article;#，然後我們把這個參數傳給 TextSqlNode 進行解析。得到的結果如下
SELECT * FROM article WHERE author = 'tianxiaobo'; DELETE FROM article;#'
看到沒，由於傳入的參數沒有經過轉義，最終導致了一條 SQL 被惡意參數拼接成了兩
條 SQL。更要命的是，第二天 SQL 會把 article 表的數據清空，這個後果就很嚴重了（從刪
庫到跑路）。這就是爲什麼我們不應該在 SQL 語句中是用${}佔位符，風險太大。
分析完 TextSqlNode 的邏輯，接下來，分析 IfSqlNode 的實現。

public class IfSqlNode implements SqlNode {
   
   
private final ExpressionEvaluator evaluator;
private final String test;
private final SqlNode contents;
public IfSqlNode(SqlNode contents, String test) {
   
   
this.test = test;
this.contents = contents;
this.evaluator = new ExpressionEvaluator();
 }
@Override
public boolean apply(DynamicContext context) {
   
   
// 通過 ONGL 評估 test 表達式的結果
if (evaluator.evaluateBoolean(test, context.getBindings())) {
   
   
// 若 test 表達式中的條件成立，則調用其他節點的 apply 方法進行解析
contents.apply(context);
return true;
 }
return false;
 } }

IfSqlNode 對應的是<iftest=‘xxx’>節點，節點是日常開發中使用頻次比較高的一個節
點。它的具體用法我想大家都很熟悉了，這裏就不多囉嗦。IfSqlNode 的 apply 方法邏輯並不複雜，首先是通過 ONGL 檢測 test 表達式是否爲 true，如果爲 true，則調用其他節點的 apply方法繼續進行解析。需要注意的是節點中也可嵌套其他的動態節點，並非只有純文本。
因此 contents 變量遍歷指向的是 MixedSqlNode，而非 StaticTextSqlNode。
關於 IfSqlNode 就說到這，接下來分析 WhereSqlNode 的實現。

public class WhereSqlNode extends TrimSqlNode {
   
   
/** 前綴列表 */
private static List<String> prefixList = Arrays.asList(
"AND ", "OR ", "AND\n", "OR\n", "AND\r", "OR\r", "AND\t", "OR\t");
public WhereSqlNode(Configuration configuration, SqlNode contents) {
   
   
// 調用父類的構造方法
super(configuration, contents, "WHERE", prefixList, null, null);
 } }

在 MyBatis 中，WhereSqlNode 和 SetSqlNode 都是基於 TrimSqlNode 實現的，所以上面
的代碼看起來很簡單。WhereSqlNode 對應於節點，關於該節點的用法以及它的應用
場景，大家請自行查閱資料。我在分析源碼的過程中，默認大家已經知道了該節點的用途和
應用場景。
接下來，我們把目光聚焦在 TrimSqlNode 的實現上。

public class TrimSqlNode implements SqlNode {
   
   
private final SqlNode contents;
private final String prefix;
private final String suffix;
private final List<String> prefixesToOverride;
private final List<String> suffixesToOverride;
private final Configuration configuration;
@Override
public boolean apply(DynamicContext context) {
   
   
// 創建具有過濾功能的 DynamicContext
FilteredDynamicContext filteredDynamicContext =
new FilteredDynamicContext(context);
// 解析節點內容
boolean result = contents.apply(filteredDynamicContext);
// 過濾掉前綴和後綴
filteredDynamicContext.applyAll();
return result;
 } }

如上，apply 方法首選調用了其他 SqlNode 的 apply 方法解析節點內容，這步操作完成
後，FilteredDynamicContext 中會得到一條 SQL 片段字符串。接下里需要做的事情是過濾字
符串前綴後和後綴，並添加相應的前綴和後綴。這個事情由 FilteredDynamicContext 負責，
FilteredDynamicContext 是 TrimSqlNode 的私有內部類。我們去看一下它的代碼。

private class FilteredDynamicContext extends DynamicContext {
   
   
private DynamicContext delegate;
/** 構造方法會將下面兩個布爾值置爲 false */
private boolean prefixApplied;
private boolean suffixApplied;
private StringBuilder sqlBuffer;
public void applyAll() {
   
   
sqlBuffer = new StringBuilder(sqlBuffer.toString().trim());
String trimmedUppercaseSql =
sqlBuffer.toString().toUpperCase(Locale.ENGLISH);
if (trimmedUppercaseSql.length() > 0) {
   
   
// 引用前綴和後綴，也就是對 sql 進行過濾操作，移除掉前綴或後綴
applyPrefix(sqlBuffer, trimmedUppercaseSql);
applySuffix(sqlBuffer, trimmedUppercaseSql);
 }
// 將當前對象的 sqlBuffer 內容添加到代理類中
delegate.appendSql(sqlBuffer.toString());
}
private void applyPrefix(StringBuilder sql, String trimmedUppercaseSql){
   
   
if (!prefixApplied) {
   
   
// 設置 prefixApplied 爲 true，以下邏輯僅會被執行一次
prefixApplied = true;
if (prefixesToOverride != null) {
   
   
for (String toRemove : prefixesToOverride) {
   
   
// 檢測當前 sql 字符串是否包含前綴，比如 'AND ', 'AND\t'等
if (trimmedUppercaseSql.startsWith(toRemove)) {
   
   
// 移除前綴
sql.delete(0, toRemove.trim().length());
break;
 }
 }
 }
// 插入前綴，比如 WHERE
if (prefix != null) {
   
   
sql.insert(0, " ");
sql.insert(0, prefix);
 }
 }
 }
// 該方法邏輯與 applyPrefix 大同小異，大家自行分析
private void applySuffix(
StringBuilder sql, String trimmedUppercaseSql){
   
   
} }

在上面的代碼中，我們重點關注 applyAll 和 applyPrefix 方法，其他的方法大家自行分
析。applyAll 方法的邏輯比較簡單，首先從 sqlBuffer 中獲取 SQL 字符串。然後調用 applyPrefix和 applySuffix 進行過濾操作。最後將過濾後的 SQL 字符串添加到被裝飾的類中。applyPrefix方法會首先檢測 SQL 字符串是不是以"AND"，“OR”，或"AND\n"，"OR\n"等前綴開頭，若是則將前綴從 sqlBuffer 中移除。然後將前綴插入到 sqlBuffer 的首部，整個邏輯就結束了。下面寫點代碼簡單驗證一下，如下：

public class SqlNodeTest {
   
   
@Test
public void testWhereSqlNode() throws IOException {
   
   
String sqlFragment = "AND id = #{id}";
MixedSqlNode msn = new MixedSqlNode(
Arrays.asList(new StaticTextSqlNode(sqlFragment)));
WhereSqlNode wsn = new WhereSqlNode(new Configuration(), msn);
DynamicContext dc = new DynamicContext(
new Configuration(), new ParamMap<>());
wsn.apply(dc);
System.out.println("解析前：" + sqlFragment);
System.out.println("解析後：" + dc.getSql());
 } }

測試結果如下

今天就先更到這，後續會繼續更新！三連支持一下吧！