MyBatis-Plus中OrderItem排序表达式的高版本兼容性问题解析

在使用MyBatis-Plus进行数据库查询时，排序功能是常见的业务需求。近期有开发者反馈在3.5.5版本中，使用OrderItem构建复杂排序表达式时遇到了SQL片段被自动过滤的问题，特别是当排序条件中包含等号(=)操作符时。

问题现象

在早期版本中，开发者可以通过以下方式构建包含CASE WHEN表达式的排序条件：

page.addOrder(OrderItem.asc("dept_name"))
    .addOrder(OrderItem.asc("CASE " +
            "WHEN comXX = 'XX' THEN 1 " +
            "WHEN comXX = 'XX' THEN 2 " +
            "ELSE 3 " +
            "END"));

但在升级到3.5.5版本后，发现生成的SQL中等于号(=)被自动过滤，导致排序逻辑失效。

问题原因分析

MyBatis-Plus在高版本中增强了SQL注入防护机制，会对传入的SQL片段进行更严格的过滤处理。这种机制会将某些特殊字符（如等号）视为潜在的安全风险而进行过滤。

这种变化体现了框架对安全性的重视，但也给需要构建复杂排序条件的开发者带来了挑战。特别是当我们需要在排序中使用条件判断表达式时，这种过滤机制会导致SQL语法不完整。

官方推荐解决方案

MyBatis-Plus官方推荐使用wrapper.last()方法来处理这类需要直接拼接SQL片段的场景：

QueryWrapper<Entity> wrapper = new QueryWrapper<>();
wrapper.last("ORDER BY dept_name ASC, 
    CASE WHEN comXX = 'XX' THEN 1 
         WHEN comXX = 'XX' THEN 2 
         ELSE 3 END ASC");

这种方法虽然解决了问题，但需要注意：

1. 直接拼接SQL存在SQL注入风险，应确保参数值的安全性
2. 这种方式会绕过MyBatis-Plus的SQL解析和优化

最佳实践建议

1. 简单排序：对于简单的字段排序，优先使用标准的addOrder方法

2. 复杂排序：对于需要条件判断的复杂排序，考虑以下替代方案：

   • 使用wrapper.last()方法（需注意安全性）
   • 在数据库层面创建计算列或视图
   • 在应用层进行排序处理

3. 安全性考虑：无论采用哪种方式，都应确保排序条件中的参数值经过适当的转义或验证，防止SQL注入攻击。

总结

MyBatis-Plus高版本对SQL片段的安全处理更加严格，这是框架发展的必然趋势。开发者在遇到类似问题时，应当理解框架的设计初衷，选择官方推荐的解决方案，同时注意平衡功能需求与安全性要求。对于复杂的业务场景，可能需要结合多种技术手段来实现既安全又灵活的排序功能。

通过这个案例，我们也看到在框架升级过程中，开发者需要关注API的变化和新的最佳实践，及时调整代码实现方式，确保应用的稳定性和安全性。