MyBatis 的 MappedStatement 和 Configuration 是什么？一条 SQL 在 MyBatis 里怎么被表示？

简化版

**MappedStatement 是 MyBatis 里「一条 SQL 语句的完整表示」——你在 Mapper XML 里写的每一个 <select>/<insert>/<update>/<delete>，或每一个 @Select 注解，都会被解析成一个 MappedStatement 对象。**它封装了这条 SQL 的一切信息：SQL 语句本身（SqlSource）、SQL 类型（增删改查）、入参类型、返回结果映射（resultMap）、缓存配置、超时、主键生成策略等。而 Configuration 是 MyBatis 的「全局配置中心」——它持有所有的 MappedStatement（一个 Map，key 是「namespace.方法名」）、所有的 TypeHandler、所有的插件、所有的设置，是整个 MyBatis 的「大脑」和「注册表」。类比理解：MappedStatement 之于 MyBatis，就像 BeanDefinition 之于 Spring——都是「把配置解析成的、描述’一个东西该怎么用’的元数据对象」。一条 SQL 执行时，MyBatis 就是拿「statement id」去 Configuration 里找到对应的 MappedStatement，按它的描述去执行 SQL、绑参数、映射结果。

详细版

MappedStatement 封装的信息：

字段	含义
id	唯一标识（namespace.方法名，如 UserMapper.selectById）
sqlSource	SQL 来源（能生成最终 SQL 和参数绑定）
sqlCommandType	SQL 类型：SELECT/INSERT/UPDATE/DELETE
parameterMap	入参映射
resultMaps	结果映射（怎么把结果集变成对象）
cache	二级缓存配置
keyGenerator	主键生成策略（自增/序列）
timeout / fetchSize / statementType	超时/抓取大小/Statement 类型

Configuration 持有的核心：

Configuration（全局配置中心）内部：
  Map<String, MappedStatement> mappedStatements   ← 所有 SQL 语句
  Map<String, ResultMap> resultMaps               ← 所有结果映射
  TypeHandlerRegistry typeHandlerRegistry         ← 所有类型处理器
  TypeAliasRegistry typeAliasRegistry             ← 所有类型别名
  InterceptorChain interceptorChain               ← 所有插件
  各种 settings（缓存、驼峰映射、懒加载等开关）
  MapperRegistry mapperRegistry                   ← 所有 Mapper 接口

一条 SQL 执行时找 MappedStatement 的过程：
  userMapper.selectById(1)
    → Mapper 代理拦截，拼出 statement id = "com.x.UserMapper.selectById"
    → configuration.getMappedStatement("com.x.UserMapper.selectById")
    → 拿到 MappedStatement
    → Executor 按它的 SqlSource 生成 SQL、绑参数、执行、按 resultMap 映射结果

⚠️ 理解 MappedStatement 和 Configuration 是「读懂 MyBatis 源码和高级机制」的钥匙，和 Spring 的 BeanDefinition/ApplicationContext 是完全对应的思想：把「配置」解析成「统一的元数据对象」，运行时按元数据干活。很多 MyBatis 的「高级操作」都是在动这两个对象：MyBatis-Plus 的 BaseMapper 单表 CRUD，本质就是启动时动态往 Configuration 里注册（addMappedStatement）一批 MappedStatement（帮你「凭空」造出 insert/select 等 SQL 语句），这和 Spring Boot「动态注册 BeanDefinition」是同一套路。理解「一条 SQL = 一个 MappedStatement，全都注册在 Configuration 的 Map 里，执行时按 id 查找」，MyBatis 的执行流程、插件机制、MP 增强就都能串起来了。

完整版教学

一、MappedStatement：一条 SQL 的完整表示

先理解 MappedStatement 承载了什么：

你在 Mapper XML 里写：
  <select id="selectById" parameterType="long" resultType="User">
    SELECT * FROM user WHERE id = #{id}
  </select>

MyBatis 解析后，这个 <select> 变成一个 MappedStatement 对象，里面记着：
  - id：UserMapper.selectById（namespace + 方法名）
  - sqlCommandType：SELECT
  - sqlSource：能生成 "SELECT * FROM user WHERE id = ?" 和参数绑定
  - resultMaps：结果按 User 映射
  - parameterType：入参是 long
  - 缓存、超时、主键策略等其他配置

所以 MappedStatement = "一条 SQL 语句的所有信息的载体"
  执行这条 SQL 需要知道的一切，都在这个对象里
  （SQL 是什么、什么类型、参数怎么绑、结果怎么映射、缓存怎么用...）

MappedStatement 是「一条 SQL 语句的完整表示」——你写的每个 <select>/@Select 都被解析成一个 MappedStatement，封装了这条 SQL 的一切（id、SQL 类型、SqlSource、结果映射、入参、缓存、主键策略等）。执行这条 SQL 需要的所有信息都在这个对象里。理解「MappedStatement 是一条 SQL 的完整表示、每个 /@Select 解析成一个、封装 SQL/类型/SqlSource/resultMap/缓存等一切信息」，就理解了它的定位。 二、SqlSource：动态 SQL 的来源 MappedStatement 里最核心的是 SqlSource——它负责「生成最终的 SQL」： SqlSource 的职责：根据入参，生成最终可执行的 SQL（BoundSql） getBoundSql(参数) → BoundSql（含最终 SQL 字符串 + 参数映射） 为什么需要它（不直接存 SQL 字符串）： 因为有"动态 SQL"（<if>、<where>、<foreach>）—— 最终 SQL 依赖运行时的参数！ 例：<if test="name!=null">AND name=#{name}</if> → name 是否为 null，决定最终 SQL 有没有这段 → 所以不能存死的 SQL 字符串，要"根据参数动态生成" SqlSource 的几种实现： DynamicSqlSource：含动态标签（<if> 等），运行时根据参数生成 SQL RawSqlSource：静态 SQL（没有动态标签，预先解析好） StaticSqlSource：最终形态（#{} 已变成 ?） 所以 SqlSource 封装了"从模板 SQL + 参数 → 最终 SQL"的逻辑 #{} 会被处理成 ? 占位符（预编译，防注入） ${} 会被直接拼进 SQL（有注入风险） MappedStatement 里最核心的是 SqlSource——它负责「根据入参生成最终可执行的 SQL（BoundSql）」。为什么不直接存 SQL 字符串？因为有动态 SQL（<if>/<foreach>），最终 SQL 依赖运行时参数，不能存死的。实现有 DynamicSqlSource（含动态标签、运行时生成）、RawSqlSource（静态预解析）等。#{} 处理成 ? 占位符（预编译防注入）、${} 直接拼接（有注入风险）。理解「SqlSource 根据入参生成最终 SQL(BoundSql)、因动态 SQL 依赖参数不能存死字符串、DynamicSqlSource/RawSqlSource、#{}→?预编译」,就理解了 SQL 生成的核心。 三、Configuration：全局配置中心 Configuration 是 MyBatis 的「大脑和注册表」，持有一切： Configuration 持有 MyBatis 运行需要的所有东西： ① mappedStatements：Map<String, MappedStatement> 所有 SQL 语句，key 是 statement id（namespace.方法名） ② resultMaps：所有结果映射 ③ typeHandlerRegistry：所有 TypeHandler（类型转换） ④ typeAliasRegistry：所有类型别名（User → com.x.User） ⑤ mapperRegistry：所有 Mapper 接口 ⑥ interceptorChain：所有插件（拦截器） ⑦ 各种 settings：缓存开关、驼峰映射、懒加载、autoMappingBehavior... ⑧ Environment：数据源、事务工厂 它是"单例的全局配置"： 一个 SqlSessionFactory 持有一个 Configuration 所有 SqlSession 共享这个 Configuration → 全局唯一的"配置中心 + 注册表" 作用：MyBatis 运行时，所有"要查配置/要找 SQL/要找 TypeHandler" 都到 Configuration 这里来 Configuration 是 MyBatis 的「全局配置中心 + 注册表」——持有所有 MappedStatement（Map，key 是 statement id）、所有 ResultMap、所有 TypeHandler、所有类型别名、所有 Mapper 接口、所有插件、所有 settings、数据源。它是单例的（一个 SqlSessionFactory 持有一个，所有 SqlSession 共享）。运行时所有「查配置/找 SQL/找 TypeHandler」都到它这里来。理解「Configuration 是全局配置中心+注册表、持有所有 MappedStatement/ResultMap/TypeHandler/插件/settings、单例被所有 SqlSession 共享」，就理解了它的定位。 四、执行一条 SQL：从 id 到 MappedStatement 把「执行 SQL」的过程串起来，看 MappedStatement 怎么被用： userMapper.selectById(1) 的执行链路： 1. Mapper 是动态代理，方法调用被 MapperProxy 拦截 2. 拼出 statement id：类全名 + 方法名 = com.x.UserMapper.selectById 3. 通过 SqlSession → configuration.getMappedStatement(id) → 从 Configuration 的 mappedStatements Map 里查出 MappedStatement 4. 交给 Executor 执行： - 用 MappedStatement 的 SqlSource.getBoundSql(参数) → 生成最终 SQL "SELECT * FROM user WHERE id = ?" + 参数[1] - StatementHandler 用 PreparedStatement 执行 - ResultSetHandler 按 MappedStatement 的 resultMaps 把结果集映射成 User 5. 返回 User 关键：statement id 是"钥匙" Mapper 方法 → statement id → Configuration 里查 MappedStatement → 执行 这就是"接口方法"和"SQL 语句"关联起来的方式：靠 id 对应 所以 Mapper 接口的"全限定名 + 方法名" 必须和 XML 的 "namespace + id" 对上 否则找不到 MappedStatement（报 BindingException） 执行一条 SQL 的链路：Mapper 代理拦截 → 拼出 statement id（类全名+方法名）→ configuration.getMappedStatement(id) 查出 MappedStatement → Executor 用它的 SqlSource 生成最终 SQL、执行、按 resultMaps 映射结果。statement id 是「钥匙」——Mapper 方法靠 id 对应到 SQL 语句，所以 Mapper 接口的「全限定名+方法名」必须和 XML 的「namespace+id」对上（否则找不到 MappedStatement，报 BindingException）。理解「执行链路:Mapper 代理→statement id→Configuration 查 MappedStatement→Executor 执行、id 是接口方法和 SQL 关联的钥匙、namespace+id 要对上」，就理解了 MappedStatement 怎么被使用。 五、类比 BeanDefinition：统一元数据思想 MappedStatement/Configuration 和 Spring 的 BeanDefinition/ApplicationContext 是同一思想： 对照（同一套"配置→元数据→运行时按元数据干活"思想）： MyBatis Spring ───────────────────────────────────────────── MappedStatement BeanDefinition （一条 SQL 的元数据） （一个 Bean 的元数据） Configuration ApplicationContext/BeanFactory （持有所有 MappedStatement） （持有所有 BeanDefinition） 解析 XML/注解 → MappedStatement 解析 XML/注解 → BeanDefinition 按 id 查 MappedStatement 执行 按 name 查 BeanDefinition 创建 Bean 共同的设计思想： ① 把"五花八门的配置"（XML、注解）解析成"统一的元数据对象" ② 元数据集中注册在一个"中心"里（Configuration / 容器） ③ 运行时按元数据干活（执行 SQL / 创建 Bean） ④ 都可以"动态注册"元数据（MP 注册 MappedStatement / Spring Boot 注册 BeanDefinition） 理解了一个，另一个就通了——都是"元数据驱动"的框架设计 MappedStatement/Configuration 和 BeanDefinition/ApplicationContext 是同一套「元数据驱动」思想：把五花八门的配置（XML/注解）解析成统一的元数据对象、集中注册在一个中心里、运行时按元数据干活、都可动态注册。对照：MappedStatement↔BeanDefinition、Configuration↔ApplicationContext。理解一个就通另一个。这是框架设计的通用范式。理解「MappedStatement/Configuration 对应 BeanDefinition/ApplicationContext、同一元数据驱动思想:配置→统一元数据→中心注册→运行时按元数据干活→可动态注册」，就把 MyBatis 和 Spring 的核心设计打通了。 六、动态注册：MyBatis-Plus 的原理 理解 MappedStatement 后，MyBatis-Plus 的 BaseMapper 原理就清晰了： MyBatis-Plus 的 BaseMapper 单表 CRUD 是怎么"凭空"来的？ → 启动时动态往 Configuration 注册 MappedStatement！ 过程： 1. MP 扫描到继承 BaseMapper 的接口 2. 找到对应的实体（@TableName、字段注解） 3. 为每个 CRUD 方法（insert/selectById/...）： - 根据实体信息拼出 SQL（INSERT INTO user ...） - 构造一个 MappedStatement - configuration.addMappedStatement(ms) ← 动态注册！ 4. 于是 Configuration 里就有了这些"你没写过"的 SQL 语句 5. 调 userMapper.selectById(1) → 按 id 找到 MP 注册的 MappedStatement → 执行 所以 MP 的"魔法"= 动态生成并注册 MappedStatement （和 Spring Boot 动态注册 BeanDefinition 是同一套路： 都是"往元数据注册表里动态加东西"） 其他类似的： 插件（拦截器）也是通过 Configuration 的 interceptorChain 生效的 → 拦截 Executor/StatementHandler 等，改写 SQL/参数/结果 理解 MappedStatement 后，MyBatis-Plus 的原理就清晰了：BaseMapper 的单表 CRUD 是 MP 启动时根据实体信息拼出 SQL、构造 MappedStatement、configuration.addMappedStatement() 动态注册——于是 Configuration 里有了「你没写过」的 SQL 语句，调用时按 id 找到它执行。这和 Spring Boot 动态注册 BeanDefinition 是同一套路（往元数据注册表动态加东西）。插件也是通过 Configuration 的 interceptorChain 生效。理解「MP 的 BaseMapper=启动时拼 SQL 构造 MappedStatement 动态注册到 Configuration、和 Spring Boot 注册 BeanDefinition 同套路、插件通过 interceptorChain 生效」，就用 MappedStatement 打通了 MyBatis 的高级机制。 记忆钩子：「MappedStatement=一条 SQL 的完整表示(每个/@Select 解析成一个,封装 id/SQL类型/SqlSource/resultMap/缓存/主键策略);SqlSource=根据入参生成最终 SQL(因动态 SQL 依赖参数不能存死字符串,#{}→?预编译);Configuration=全局配置中心+注册表(单例,持有所有 MappedStatement(Map,key=namespace.方法名)/TypeHandler/插件/settings,所有 SqlSession 共享);执行:Mapper 代理→statement id→Configuration 查 MappedStatement→Executor 执行;★类比 Spring:MappedStatement↔BeanDefinition、Configuration↔ApplicationContext(同一元数据驱动思想);MyBatis-Plus 的 BaseMapper=启动时动态 addMappedStatement(和 Spring Boot 注册 BeanDefinition 同套路)」。

七、常见误区与追问

• 误区：MyBatis 直接存 SQL 字符串去执行。 存的是 MappedStatement（含 SqlSource），因为有动态 SQL（/），最终 SQL 依赖运行时参数、不能存死字符串；SqlSource.getBoundSql(参数) 才生成最终 SQL 和参数绑定。
• 误区：MappedStatement 只是存了 SQL 语句。 它封装一条 SQL 的「一切」——id、SQL 类型、SqlSource、入参类型、结果映射 resultMap、缓存配置、主键生成策略、超时等；执行这条 SQL 需要的所有信息都在里面。
• 误区：Configuration 是可有可无的配置类。 它是 MyBatis 的「大脑和注册表」——单例、持有所有 MappedStatement/TypeHandler/插件/settings，所有 SqlSession 共享；运行时所有查配置、找 SQL、找类型处理器都到它这里，没它 MyBatis 无法运行。
• 误区：Mapper 接口方法和 XML 里的 SQL 是随意对应的。 靠 statement id 严格对应——Mapper 接口的「全限定名+方法名」必须和 XML 的「namespace+id」对上，MyBatis 才能用这个 id 从 Configuration 里找到对应的 MappedStatement；对不上会报 BindingException。
• 追问：MyBatis-Plus 的 BaseMapper 单表 CRUD 底层是什么？ MP 启动时扫描继承 BaseMapper 的接口，根据实体信息（@TableName、字段）拼出 insert/select 等 SQL，构造成 MappedStatement，调 configuration.addMappedStatement() 动态注册到 Configuration；于是这些「你没写过」的 SQL 语句就有了，调用时按 id 找到执行——和 Spring Boot 动态注册 BeanDefinition 同一套路。
• 追问：MappedStatement 和 Spring 的 BeanDefinition 有什么共同点？ 都是「把配置（XML/注解）解析成的、描述’一个东西该怎么用’的统一元数据对象」，集中注册在一个中心（Configuration/容器）里，运行时按元数据干活（执行 SQL/创建 Bean），且都能动态注册——是「元数据驱动」框架设计的同一范式。
• 追问：一条动态 SQL（含 ）的最终 SQL 是什么时候确定的？ 运行时——MappedStatement 里的 SqlSource 是 DynamicSqlSource，执行时调 getBoundSql(参数)，根据传入的参数判断 等动态标签，拼出最终的 SQL 字符串和参数绑定（BoundSql）；所以同一个 MappedStatement 不同参数可能生成不同的最终 SQL。

八、加强记忆

MappedStatement 是 MyBatis 里「一条 SQL 语句的完整表示」——每个 <select>/<insert>/@Select 都被解析成一个 MappedStatement，封装这条 SQL 的一切：id（namespace.方法名）、SQL 类型、SqlSource（根据入参生成最终 SQL，因动态 SQL 依赖参数不能存死字符串，#{}→? 预编译）、结果映射 resultMap、缓存、主键策略等。Configuration 是 MyBatis 的「全局配置中心 + 注册表」——单例（一个 SqlSessionFactory 持有一个、所有 SqlSession 共享），持有所有 MappedStatement（Map，key 是 statement id）、所有 TypeHandler、所有插件、所有 settings、数据源。执行一条 SQL：Mapper 代理拦截 → 拼出 statement id → configuration.getMappedStatement(id) 查出 → Executor 用它的 SqlSource 生成 SQL、执行、按 resultMaps 映射结果（id 是接口方法和 SQL 关联的钥匙，namespace+id 必须对上否则 BindingException）。类比 Spring：MappedStatement↔BeanDefinition、Configuration↔ApplicationContext——同一「元数据驱动」思想（配置解析成统一元数据、集中注册、运行时按元数据干活、可动态注册）。MyBatis-Plus 的 BaseMapper 就是启动时拼 SQL、构造 MappedStatement、addMappedStatement() 动态注册（和 Spring Boot 注册 BeanDefinition 同套路）。一句话「MappedStatement=一条 SQL 的完整元数据(id/SqlSource/resultMap/缓存),Configuration=持有所有 MappedStatement 的全局注册表(单例);执行按 statement id 查 MappedStatement;类比 BeanDefinition/ApplicationContext(元数据驱动);MP 的 BaseMapper=动态 addMappedStatement」。