MyBatis-Plus 在达梦数据库中的索引失效问题分析与解决方案

问题背景

在使用 MyBatis-Plus (简称 MP) 框架操作达梦数据库(DM)时，开发人员遇到了一个特殊现象：相同的查询逻辑，使用 MyBatis-Plus 的 QueryWrapper 构建的 SQL 与直接使用 MyBatis XML 方式编写的 SQL 在执行效率上存在显著差异，表现为 QueryWrapper 生成的 SQL 查询不走索引，导致查询性能急剧下降。

问题现象

开发人员报告了两种典型场景：

场景一：IN 查询性能差异

使用 QueryWrapper 构建的 IN 查询：

LambdaQueryWrapper<CenterDiseaseDetail> wrapper = new LambdaQueryWrapper<>();
wrapper.in(CenterDiseaseDetail::getIdcard, idcardList);
wrapper.select(CenterDiseaseDetail::getIdcard, CenterDiseaseDetail::getCode);

生成的 SQL：

SELECT idcard,code FROM center_disease_detail WHERE (idcard IN ('DEMO00195403160202','DEMO00197301071002',...))

执行时间：1分30秒

而使用 XML 方式编写的相同查询：

<select id="find">
    select idcard,code from center_disease_detail where idcard IN
    <foreach collection="idcardList" item="idcard" separator="," open="(" close=")">
        #{idcard}
    </foreach>
</select>

生成的 SQL：

select idcard,code from center_disease_detail where idcard IN ( 'DEMO00195403160202' , 'DEMO00197301071002' , ... )

执行时间：仅 70 毫秒

场景二：条件顺序影响索引使用

使用 QueryWrapper 构建的查询：

QueryWrapper<CenterFollowHbpDrug> wrapper = new QueryWrapper<>();
wrapper.lambda()
    .eq(CenterFollowHbpDrug::getStatus, 0)
    .eq(CenterFollowHbpDrug::getPid, "2016070100899052_542101");

生成的 SQL：

SELECT ... FROM center_follow_hbp_drug WHERE (status = 0 AND pid = '2016070100899052_542101')

执行时间：15秒

而调换条件顺序后：

QueryWrapper<CenterFollowHbpDrug> wrapper = new QueryWrapper<>();
wrapper.lambda()
    .eq(CenterFollowHbpDrug::getPid, "2016070100899052_542101")
    .eq(CenterFollowHbpDrug::getStatus, 0);

生成的 SQL：

SELECT ... FROM center_follow_hbp_drug WHERE (pid = '2016070100899052_542101' AND status = 0)

执行时间：99毫秒

问题分析

通过对比分析，可以发现以下几个关键差异点：

1. 括号使用差异：QueryWrapper 生成的 SQL 在 WHERE 条件外额外添加了括号，而 XML 方式没有
2. 逗号格式差异：IN 查询中，QueryWrapper 生成的 SQL 列表项间没有空格，而 XML 方式有
3. 条件顺序差异：QueryWrapper 按照代码编写顺序生成条件，而达梦数据库对此敏感

进一步测试发现，以下修改可以使 QueryWrapper 生成的 SQL 恢复正常性能：

1. 在 SQL 末尾添加无关注释（如 wrapper.last("--")）
2. 手动为查询字段添加空格（如 wrapper.select("idcard ", "code ")）
3. 显式指定所有查询字段而非使用 select(*)

这些现象表明，达梦数据库的查询优化器对 SQL 的格式非常敏感，微小的语法差异可能导致其无法正确使用索引。

根本原因

经过深入排查，确定问题根源在于：

1. 达梦数据库的特殊性：达梦数据库作为国产数据库，其查询优化器实现与主流数据库存在差异，对 SQL 语法格式更为敏感
2. MyBatis-Plus 的 SQL 生成策略：框架默认生成的 SQL 格式（如括号使用、逗号格式）与达梦数据库优化器的预期不完全匹配
3. 环境差异：问题仅出现在特定版本的达梦数据库生产环境，测试环境无法复现，说明与数据库具体实现版本有关

解决方案

针对这一问题，开发人员提出了以下几种解决方案：

临时解决方案

1. SQL 格式调整拦截器：

public class DmInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        if (target instanceof StatementHandler statementHandler) {
            String originalSql = statementHandler.getBoundSql().getSql();
            String newSql = originalSql.replaceAll(",", ", ");
            // 更新 SQL 语句
            Field field = statementHandler.getBoundSql().getClass().getDeclaredField("sql");
            field.setAccessible(true);
            field.set(statementHandler.getBoundSql(), newSql);
        }
        return invocation.proceed();
    }
}

此拦截器会自动在所有 SQL 的逗号后添加空格，解决格式敏感问题。

2. 手动调整 QueryWrapper 使用方式：

// 添加无关注释
wrapper.last("--");

// 或手动添加空格
wrapper.select("idcard ", "code ");

长期建议

1. 达梦数据库配置调整：联系达梦数据库技术支持，了解是否有优化器模式或兼容性设置可以调整
2. 框架层适配：考虑为达梦数据库实现特定的 SQL 生成策略
3. 监控与反馈：持续关注达梦数据库版本更新，及时升级可能修复此问题的版本

最佳实践建议

对于在达梦数据库中使用 MyBatis-Plus 的开发团队，建议：

1. 对关键查询进行性能测试，比较 QueryWrapper 与 XML 方式的差异
2. 建立 SQL 执行监控机制，及时发现潜在的性能问题
3. 保持与数据库厂商的沟通，了解最新优化建议
4. 考虑封装统一的查询构建工具，确保生成的 SQL 格式符合达梦数据库优化器的要求

总结

这一问题揭示了国产数据库在实际应用中的特殊性和挑战。虽然通过技术手段可以解决当前问题，但长期来看，需要数据库厂商、框架开发者和应用开发者共同努力，才能实现更好的兼容性和性能表现。MyBatis-Plus 作为流行的 ORM 框架，在面对多样化的数据库环境时，也需要考虑更多的适配策略。