MyBatis 的 Mapper 接口为什么不需要实现类？SQL 是怎样被执行的？

知识点详解：一次 Mapper 方法调用，怎样到达数据库

首先拿到的对象，是接口代理

咱们假设存在一个 OrderMapper 接口，里面声明按 ID 查询订单的方法。应用获得的 Mapper 对象不是这个接口本身，而是能够实现该接口调用入口的代理。

当方法被调用时，代理接收方法信息和参数，再交给 MyBatis 的处理逻辑。官方 MapperProxy 源码能够直接看到调用委托与方法缓存等逻辑。

这里说“实现接口”，是代理对象在调用层满足接口，不是 MyBatis 根据方法名自动猜出所有业务 SQL。没有映射、映射不匹配或配置错误，调用仍然会失败。

接口方法，要找到明确的映射语句

对于常见 XML 映射，接口全限定名与方法名一起构成查找映射的重要依据。namespace 和语句 id 对不上，就可能出现找不到绑定语句的问题。

因此，不能随意在同一个 Mapper 中用 Java 方法重载来期待按不同参数自动找到不同 XML id。XML id 的识别规则并不是 Java 的完整重载签名。

MyBatis Java API 文档介绍了 Mapper 接口与 SqlSession 使用方式。具体还包括注解映射、默认方法等边界，不能把所有接口方法都说成“必然执行一条同名 SQL”。

图以 XML 映射为例；注解等方式也可以注册映射语句。

参数处理和 SQL 执行，是后面的工作

找到 MappedStatement 以后，MyBatis 还需要根据参数生成实际 SQL 信息，处理参数绑定，再通过执行组件与 JDBC 访问数据库。

咱们的查询条件是订单 ID，这个值应通过参数绑定进入 SQL，而不是直接拼成任意字符串。动态 SQL 中不同占位方式有不同安全影响，不能因为使用了 Mapper 就认为 SQL 注入问题已经消失。

执行器还涉及缓存和不同执行方式。它不是每次都机械地发送完全相同的数据库请求；具体行为受到会话、事务和配置影响。不过，本题重点是执行链，不展开重新讲一遍缓存专题。

返回一行记录，还不等于返回业务对象

数据库给出结果后，MyBatis 根据结果映射，把列值转换成对象字段或其他返回形式。

如果方法要求一个订单对象，而列名与属性不匹配，就可能出现字段为空或映射错误。是否使用别名、自动映射或 resultMap，要看实际配置。

因此，一次调用可以按这条主线理解：

Mapper 代理 → 方法与 SQL 映射 → 参数处理
→ Executor / JDBC → 结果映射 → 方法返回值

Spring 集成，增加的是会话与事务管理

在 Spring 项目中，通常不是每次手动打开和关闭 SqlSession。MyBatis-Spring 的相关组件参与会话生命周期和 Spring 事务管理。

MyBatis-Spring 的 SqlSession 说明解释了这种集成。事务边界仍需要正确配置；拿到代理并不证明多个数据库操作已经处在同一业务事务里。

这也是为什么“Mapper 就是一个接口”不能解释全部运行行为。接口只是入口，后面还有明确的映射和资源管理链路。

面试官继续追问

方法名写对了，为什么还是提示找不到语句？

还要检查 namespace、映射文件是否加载、扫描配置及实际接口全限定名。只看方法名不足以确定绑定成功。

能不能在 Mapper 默认方法里写逻辑？

可以存在默认方法，但要按框架支持和版本核对。默认方法与普通映射方法的处理不同，不应一概描述成 SQL 查询。

为什么本题不提供 TS 和 Python 版本？

MyBatis 是 Java 框架，没有同一套官方 TS、Python API。机械翻译会把框架机制写错，所以这里用执行链说明，不伪造对应实现。

面试速记卡

• Mapper 对象：接口代理，不是接口自己执行 SQL。
• 映射入口：接口与方法信息定位已注册语句。
• 执行链路：映射、参数、执行器、JDBC、结果转换。
• Spring 集成：额外管理 SqlSession 和事务参与。
• 排查方法：逐段检查，不把所有错误归因于代理。