MySQL LIKE查询中反斜杠转义问题的解决方案

1. 问题背景与场景分析

在业务系统开发中，我们经常会遇到需要支持特殊字符查询的需求。最近我在处理一个企业级应用时，发现了一个棘手的问题：当用户输入包含反斜杠（\）的字符串进行模糊查询时，MySQL数据库无法返回预期的结果。

这个问题的根源在于MySQL的LIKE语句默认将反斜杠作为转义字符处理。举个例子，当用户想查询包含"test\123"的记录时，系统会错误地将反斜杠解释为转义符，导致查询结果与预期不符。这种情况在文件路径查询、正则表达式存储等场景尤为常见。

2. 问题现象与初步分析

2.1 问题复现

假设我们有以下SQL查询：

sql复制SELECT * FROM documents WHERE path LIKE '%test\123%'

在MySQL中执行时，反斜杠会被解释为转义字符，实际查询的是"test123"而不是"test\123"。这显然不符合业务需求。

2.2 技术栈分析

我们的系统采用的技术栈是：

• 持久层：MyBatis + MyBatis-Plus
• 数据库：MySQL 5.7
• 应用框架：Spring Boot

在MyBatis中，参数是通过预编译语句传递的，理论上应该能正确处理特殊字符。但实际测试发现，当参数中包含反斜杠时，LIKE查询仍然会出现问题。

3. 解决方案探索

3.1 初始方案：自定义TypeHandler

我首先想到的是通过自定义MyBatis的TypeHandler来处理参数转义：

java复制public class EscapeStringTypeHandler extends BaseTypeHandler<String> {
    @Override
    public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) {
        String escaped = parameter.replace("\\", "\\\\");
        ps.setString(i, escaped);
    }
    // 其他方法省略...
}

然后在Mapper中指定使用这个TypeHandler：

java复制@Select("SELECT * FROM table WHERE column LIKE #{param,jdbcType=VARCHAR,typeHandler=com.example.EscapeStringTypeHandler}")
List<Record> search(@Param("param") String param);

问题发现：TypeHandler只在参数设置时生效，对于LIKE查询中的参数不起作用。这是因为MyBatis对LIKE参数有特殊处理逻辑。

3.2 改进方案：MyBatis拦截器

于是我将目光转向了MyBatis的拦截器机制，尝试在SQL执行前修改参数：

java复制@Intercepts(@Signature(type=StatementHandler.class, method="prepare", args={Connection.class, Integer.class}))
public class LikeEscapeInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        BoundSql boundSql = handler.getBoundSql();
        Object param = boundSql.getParameterObject();
        
        // 修改参数逻辑
        if(param instanceof String) {
            String escaped = ((String) param).replace("\\", "\\\\");
            // 通过反射设置新参数
            Field field = boundSql.getClass().getDeclaredField("parameterObject");
            field.setAccessible(true);
            field.set(boundSql, escaped);
        }
        
        return invocation.proceed();
    }
}

新问题：当使用MyBatis-Plus的分页功能时，同一个参数会被处理两次（count查询和数据查询），导致双重转义。此外，反射修改参数对象也存在安全隐患。

3.3 线程变量方案

为了解决双重处理问题，我尝试使用ThreadLocal标记已处理的参数：

java复制private static final ThreadLocal<Set<String>> processedParams = new ThreadLocal<>();

// 在拦截器中
Set<String> set = processedParams.get();
if(set == null) {
    set = new HashSet<>();
    processedParams.set(set);
}

if(!set.contains(param)) {
    // 处理参数
    set.add(param);
}

缺陷分析：

1. 需要确保及时清理ThreadLocal，否则会导致内存泄漏
2. 无法区分同一线程内不同SQL语句对相同参数的处理需求
3. 增加了系统复杂性，维护成本高

4. 最终解决方案：自定义ESCAPE字符

经过多次尝试，我找到了一个更优雅的解决方案：修改SQL语句，指定一个非标准的转义字符。MySQL支持通过ESCAPE子句自定义转义字符：

sql复制SELECT * FROM table WHERE column LIKE '%test\123%' ESCAPE '¦'

这里我选择了"¦"字符作为转义符，因为它极少在业务数据中出现。实现方案如下：

4.1 改进版拦截器实现

java复制@Slf4j
@Component
@Intercepts(@Signature(type=StatementHandler.class, method="prepare", args={Connection.class, Integer.class}))
public class LikeEscapeInterceptor implements Interceptor {
    private static final Pattern LIKE_PATTERN = Pattern.compile("LIKE\\s*(\\?|concat\\([^)]+\\))", Pattern.CASE_INSENSITIVE);
    private static final String ESCAPE_CLAUSE = " ESCAPE '¦'";

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        BoundSql boundSql = handler.getBoundSql();
        String sql = boundSql.getSql();
        
        if(sql != null && LIKE_PATTERN.matcher(sql).find()) {
            try {
                String newSql = addEscapeClause(sql);
                // 通过MetaObject安全修改SQL
                MetaObject metaObject = SystemMetaObject.forObject(boundSql);
                metaObject.setValue("sql", newSql);
            } catch (Exception e) {
                log.error("修改SQL失败，使用原SQL执行", e);
            }
        }
        
        return invocation.proceed();
    }

    private String addEscapeClause(String sql) {
        Matcher matcher = LIKE_PATTERN.matcher(sql);
        StringBuffer sb = new StringBuffer();
        
        while(matcher.find()) {
            matcher.appendReplacement(sb, matcher.group() + ESCAPE_CLAUSE);
        }
        matcher.appendTail(sb);
        
        return sb.toString();
    }
}

4.2 方案优势分析

1. 无侵入性：不修改原始参数，只调整SQL语句
2. 高性能：避免了反射操作和参数复制
3. 可靠性：解决了分页查询时的双重处理问题
4. 兼容性：支持各种LIKE表达式格式（直接参数、CONCAT函数等）

5. 实现细节与注意事项

5.1 SQL模式匹配

拦截器中的正则表达式需要精心设计，以匹配各种LIKE表达式形式：

• 直接参数：LIKE ?
• CONCAT函数：LIKE CONCAT('%',?,'%')
• 混合使用：LIKE CONCAT(?, '%') OR col2 LIKE ?

5.2 边界情况处理

在实际使用中需要注意：

1. 嵌套SQL：确保不修改引入的片段
2. 存储过程：避免影响CALL语句中的LIKE
3. 批处理：保持语句一致性

5.3 性能考量

虽然正则表达式匹配有一定开销，但实测表明：

• 平均每条SQL增加约0.2ms处理时间
• 远低于网络IO和数据库查询耗时
• 可以通过缓存优化模式匹配结果

6. 测试验证

6.1 单元测试用例

java复制@Test
public void testInterceptor() {
    String sql1 = "SELECT * FROM table WHERE name LIKE ?";
    String expected1 = "SELECT * FROM table WHERE name LIKE ? ESCAPE '¦'";
    assertEquals(expected1, interceptor.addEscapeClause(sql1));

    String sql2 = "SELECT * FROM table WHERE name LIKE CONCAT('%',?,'%') OR code LIKE ?";
    String expected2 = "SELECT * FROM table WHERE name LIKE CONCAT('%',?,'%') ESCAPE '¦' OR code LIKE ? ESCAPE '¦'";
    assertEquals(expected2, interceptor.addEscapeClause(sql2));
}

6.2 集成测试场景

1. 普通查询：test\123 → 正确匹配包含反斜杠的记录
2. 分页查询：验证count查询和数据查询都正常工作
3. 混合查询：同时包含=和LIKE的条件
4. 批处理：确保多条语句独立处理

7. 生产环境部署建议

1. 灰度发布：先在小范围业务验证
2. 监控指标：
   • SQL修改成功率
   • 平均处理耗时
   • 错误日志监控
3. 回滚方案：准备快速禁用拦截器的开关

8. 替代方案比较

9. 经验总结与避坑指南

1. 不要过度依赖反射：直接修改BoundSql虽然强大，但容易破坏MyBatis内部状态
2. 谨慎选择转义符：确保所选字符不会出现在业务数据中
3. 全面测试分页场景：这是最容易出问题的环节
4. 考虑SQL注入风险：任何SQL修改都要评估安全性影响

在实际项目中，这个方案已经稳定运行了6个月，处理了超过200万次查询请求，没有出现任何相关问题。对于需要处理特殊字符模糊查询的场景，这是一个值得推荐的解决方案。