MyBatis查询Oracle数据库结果与客户端不一致的排查与解决

问题场景描述

在开发过程中，遇到 MyBatis 查询 Oracle 表的结果与直接使用 SQL 客户端（如 DBeaver）执行的结果不一致。测试环境建表语句如下：

CREATE TABLE t_test_table (
"ID" NUMBER(18,0), 
"CREATE_TIME" TIMESTAMP(6),
"FIELD_TYPE" CHAR(20),
CONSTRAINT pk_id PRIMARY KEY(ID)
)

插入少量测试数据后，在客户端中查询确认数据已存在：

随后在 MyBatis XML Mapper 中使用 #{} 预编译方式查询：

<select id="selectByFieldType" resultType="com.scd.model.po.TestTable">
    SELECT * FROM T_TEST_TABLE WHERE FIELD_TYPE = #{filedType}
</select>

运行时 Debug 日志显示参数传递正常，但返回总记录数为 0：
==> Parameters: Double(String)
<== Total: 0

然而，将生成的 SQL 复制到 DBeaver 等客户端直接执行时，却能正确查到数据：

初步排查：预编译与字符串拼接的差异

日志中的 SQL 语句与客户端执行的 SQL 文本一致，唯一的区别在于 MyBatis 使用了预编译占位符 ?，而客户端是直接拼接后的静态 SQL。
为了验证是否是预编译机制导致的问题，尝试将 XML 改为字符串拼接模式 ${} ：

<select id="selectByFieldType" resultType="com.scd.model.po.TestTable">
    SELECT * FROM T_TEST_TABLE WHERE FIELD_TYPE = '${filedType}'
</select>

此时再次运行，日志显示成功返回 1 条数据：
Preparing: SELECT * FROM T_TEST_TABLE WHERE FIELD_TYPE = 'Double'
Total: 1

虽然问题似乎解决了，但在企业级开发规范中，XML 配置严禁使用 ${} 进行字符串拼接，以防止 SQL 注入攻击。因此，必须深入探究为何 #{} 预编译会失效。

深入排查：源码调试与JDBC复现

对比两种执行情况，核心差异在于“设置参数”的过程。通过断点调试 MyBatis 源码，定位到参数设置入口 org.apache.ibatis.scripting.defaults.DefaultParameterHandler#setParameters：

由于未指定特定的 TypeHandler，MyBatis 根据传入值的 Java 类型匹配默认处理器。对于 String 类型的 "Double"，系统匹配到了 StringTypeHandler 进行处理：

继续向下跟踪，查看具体设置 SQL 参数的代码段，逻辑看起来并无异常：

鉴于源码层面无明显 Bug，进一步简化问题，剥离 MyBatis 层，直接使用纯 JDBC 模拟预编译执行逻辑进行测试：

public void testStrQuery() {
    try (Connection connection = createConnection(url, userName, password)) {
        String sql = "SELECT * FROM T_TEST_TABLE WHERE FIELD_TYPE = ?";
        PreparedStatement preparedStatement = connection.prepareStatement(sql);
        preparedStatement.setString(1, "Double"); // 手动填入字符串
        preparedStatement.execute();
        while (preparedStatement.getMoreResults()) {
            System.out.println(preparedStatement.getResultSet());
        }
    } catch (SQLException e) {
        e.printStackTrace();
    }
}

测试结果同样无法获取数据。这说明问题根源不在 MyBatis，而是 Oracle JDBC 驱动在处理 CHAR 类型时的行为差异。

终极真相：Oracle CHAR字段的空格填充机制

既然代码没问题，我们查看 Oracle 服务器端的 SQL 解析日志，观察底层执行计划：

select * from v$sql WHERE SQL_TEXT LIKE '%T_TEST_TABLE%'

可以看到，预编译的执行计划中，条件保留为 = :1；而直接拼接的 SQL 变成了 = 'Double'。在客户端手动执行带冒号的预编译语句也是可以的（如 所示），这让人困惑。 关键线索出现在对原始数据的观察上。当我们直接将数据库中的字段值复制出来粘贴时，发现末尾隐藏了一个空格：

查阅 Oracle 文档可知，CHAR(n) 是定长字符类型。当插入的值长度不足 n 时，Oracle 会自动用空格填充至长度 n。本例中字段定义为 CHAR(20)，插入 'Double'（长度6）后，数据库实际存储的是 'Double '（后面有14个空格）。 为什么预编译查不到呢？因为 JDBC 驱动在绑定参数时，为了性能优化或与特定版本兼容，可能对定长类型的比较进行了严格的字节对齐或修剪处理，导致传入的 "Double" 无法匹配数据库里 'Double ' 这种带有尾随空格的值。而客户端某些工具在执行直接拼接或不同风格的 SQL 时，可能触发了不同的隐式转换逻辑或直接忽略了尾部空格。

解决方案

最彻底的解决方法是修正表结构，将不适合动态长度的字段类型由 CHAR 改为 VARCHAR2，并清理现有数据中的冗余空格。

第一步：修改字段类型

ALTER TABLE T_TEST_TABLE MODIFY "FIELD_TYPE" VARCHAR2(20);

第二步：清理历史数据的尾随空格

UPDATE T_TEST_TABLE SET FIELD_TYPE = TRIM(FIELD_TYPE);

完成上述操作后，重新使用 MyBatis 原有的 #{} 预编译方式查询，即可正常获取预期数据：

总结

本文通过一个典型的 MyBatis 与 Oracle 交互案例，揭示了 CHAR 类型隐式空格填充对预编译参数匹配的影响。在实际开发中，建议优先使用 VARCHAR2 替代 CHAR 以避免此类隐蔽问题。同时，面对框架行为异常时，结合源码调试、JDBC 复现及数据库底层视图分析，是定位问题的有效路径。

以上就是MyBatis SQL执行结果与客户端不一致问题排查的详细内容，更多关于MyBatis与Oracle交互优化的资料请关注本站其它相关文章！