Notes on the MyBatis 3.5 Source Code: Executors, Dynamic SQL, and Caching Boundaries

·(edited)· / , , , , · reads

This article was last modified on . Some content may be outdated. Feel free to ask the author if you have questions.

AI TranslationSimplified ChineseEnglish

Key Insights

SqlSession是MyBatis的门面接口，负责委派给内部的Executor来执行SQL语句，并管理事务、缓存等。Executor有多种实现类型，如SimpleExecutor、ReuseExecutor、BatchExecutor和CachingExecutor，每种适用于不同的场景优化。SqlSource提供静态和动态SQL构建，动态SQL利用SqlNode树表示复杂逻辑。参数处理通过ParameterMapping和OGNL表达式求值，保证SQL安全。ResultMap提供结果集到对象的映射，支持自动映射、嵌套结果等。MyBatis有一级缓存与二级缓存机制，缓存实现了缓存装饰器模式。插件与拦截器用于扩展核心组件，能实现分页、分库分表、性能监控等功能。事务管理由Transaction接口和JdbcTransaction实现，支持事务隔离级别配置。反射和工具类简化对象操作，类型处理由TypeHandlerRegistry管理。日志与调试使得开发者及时定位问题。SQL重用与优化策略包括缓存、预编译SQL、批量操作等。最后，对日常开发带来的启发包括设计模式应用、架构思想、实战经验总结，并介绍了MyBatis-Spring集成和分页插件实现原理。

Notes on the MyBatis 3.5 Source Code: Executors, Dynamic SQL, and Caching Boundaries

Baseline: MyBatis 3.5.x, Spring Boot 3, Java 17+.

1. From SqlSession to JDBC

The typical call chain is:

TEXT

SqlSession -> Executor -> StatementHandler -> JDBC Statement
                                      -> ResultSetHandler

SqlSession acts as a facade, while Executor handles SQL execution, transactions, and caching. MappedStatement describes the mapped SQL, StatementHandler handles parameter binding and execution, and ResultSetHandler constructs the result objects.

2. Dynamic SQL and Parameters

XML dynamic nodes are ultimately assembled into a SqlSource. #{} generates a parameter mapping and uses a PreparedStatement; ${} performs string substitution and may only be used for allowlisted table names, column names, and sort fields.

OGNL evaluates some dynamic expressions, but its expression capabilities do not define the security boundary. Never allow untrusted input to control expressions or SQL structure.

3. Executor

SimpleExecutor creates a new Statement for each execution; ReuseExecutor reuses Statements; BatchExecutor defers updates for batch processing; CachingExecutor decorates another Executor to provide a namespace-level second-level cache.

The choice of Executor should account for transactions, failure-retry behavior, memory usage, and JDBC driver behavior. BatchExecutor is not necessarily faster just because it has been enabled.

4. First- and Second-Level Caches

The first-level cache usually lives within the SqlSession/Executor lifecycle, so long-lived reuse may return stale data. The second-level cache is namespace-scoped and must account for serialization, transaction commits, and invalidation consistency. Second-level caching should not be enabled by default in scenarios that require strong consistency across instances.

5. How to Read the Source Code

Start by following the Mapper proxy, then trace MappedStatement registration, the Executor decorator chain, ParameterMapping, TypeHandler, and ResultMap. When upgrading, rely on the source code for the exact version you have pinned, and do not treat internal fields as a stable API.