动态拼接SQL实践备忘📝

注:

本文无源码分析

单纯记录@SelectProvider实践，年纪大了(无奈的笑)，备忘一下📝

演示的都是最简单的场景最简单的代码，无法代表业务的复杂性

背景介绍

最近工作接到一个荒诞的任务，实际情况比较复杂，总结一下有以下特点

返回的字段如幽灵般游移不定
目标表仿佛在迷雾中随每次请求变化
过滤条件无规则无限制任意搭配

Mybatis的XML模板沉默以对，Mybatis-Plus的Wrapper亦束手无策。这让我想起 Navicat 的"筛选"功能，感觉两者有些相似，只不过Navicat场景更加简单一些。

于是，在荒诞的尽头，笔者做出了一个近乎宿命的选择：亲手拼接SQL------不是出于信念，而是因为别无选择。在这片逻辑崩塌的废墟上，唯有将字符串缝合成一句句临时的祷词，交付给数据库那沉默而全能的神谕。一旦接受了这种徒劳的合理性，道路便在虚无中浮现。

JdbcTemplate

那是来自Spring最原始的呼唤，一种近乎本能的回归。在框架层层叠叠的抽象迷宫中迷失之后，我听见了它低沉而直接的声音：没有装饰，没有隐喻，只有queryForMap与queryForList赤裸裸地横亘于代码之中。我们熟悉它，正如熟悉自己的双手。

java 复制代码

public class JdbcTemplate extends JdbcAccessor
    implements JdbcOperations {
    
    /* 获取单条记录 */
    @Override
    public Map<String, Object> queryForMap(String sql)
        throws DataAccessException {
        return result(queryForObject(sql, getColumnMapRowMapper()));
    }
    
    /* 获取多条记录 */
    @Override
    public List<Map<String, Object>> queryForList(String sql) 
        throws DataAccessException {
        return query(sql, getColumnMapRowMapper());
    }

}

然而这朴素之中藏着代价。它不够优雅，更谈不上智能。而当多数据源的阴影悄然降临，它便显露出更深的无力：每一次切换，都像在荒原上重新挖一口井，徒增重复、耦合与混乱。于是，这份最初的慰藉，终究在现实的重压下显出裂痕------它能承载希望，却无法驯服复杂。

@SelectProvider

后来，我遇见了 SelectProvider------它披着优雅的外衣，携带着一种近乎诗意的承诺。

java 复制代码

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Repeatable(SelectProvider.List.class)
/* 该注解允许定制多种选项，平常使用这两个即可 */
public @interface SelectProvider {

    /* 填写生产SQL语句的类 */
    Class<?> type() default void.class;
    
    /* 填写生产SQL语句的方法名 */
    String method() default "";

}

只需在方法上轻轻标注，指明谁将为SQL赋形、何处孕育语句，MyBatis 便会如虔诚的信使，自动召唤那段动态生成的咒语，并将其送入数据库的圣殿。代码简洁，结构清晰，仿佛终于在这查询迷局中，找到了一丝理性的秩序。

java 复制代码

/**
 * @author Raphael
 * @since 2025-11-19 15:21
 */
@DS("report")
@Mapper
public interface TestMapper {

    @SelectProvider(type = SqlProvider.class, method = "findById")
    Map<String, Object> findById(String tbl, String id);
  
    /* SQL语句提供类 */
    static class SqlProvider {

        /* 提供语句的方法 */
        public static String findById(String tbl, String id) {
            return "select * from " + tbl + " where id = " + id;
        }
        
    }
    
}

然而，这优雅之下潜伏着古老的危险：若对输入不加审视，任其流入拼接的缝隙，SQL 注入便如幽灵般悄然附体------一句恶意的字符串，足以撕裂整个系统的防线。因此，我不得不低声警告：凡使用此道者，必先以转义为盾，以校验为矛，方可在自由与安全之间行走。

java 复制代码

/**
 * @author Raphael
 * @since 2025-11-19 15:21
 */
@DS("report")
@Mapper
public interface TestMapper {

    @SelectProvider(type = SqlProvider.class, method = "getById")
    Map<String, Object> getById(String tbl, String id);
  
    /* SQL语句提供类 */
    static class SqlProvider {

        /* 提供语句的方法 */
        public static String getById(@Param("tbl")String tbl, @Param("id") String id) {
            return new SQL()
                .SELECT("*")
                .FROM("tbl = #{tbl}")
                .WHERE("id = #{id}")
                .toString();
        }
        
    }
    
}

更令人踟蹰的是性能之问。有人提议缓存生成的 SQL，以避重复构造之耗。可这念头本身便陷入悖论：若 SQL 真能被缓存，那意味着其形式已然趋于稳定；

java 复制代码

private static final String SQL =
    new SQL()
        .SELECT("*")
        .FROM("#{tbl}")
        .WHERE("id = #{id}")
        .toString();

public static String getById(@Param("tbl")String tbl, @Param("id") String id) {
    return SQL;
}

而若形式稳定，又何须动用SelectProvider这般为混沌而生的机制？这就像试图为风塑形，再宣称它的轮廓可以复用。

总结

回望整个探索过程，从 JdbcTemplate 的直白拼接到 SelectProvider 的动态封装，每一种方案都像是在不确定性的迷宫中点亮一盏临时的灯------足够照亮脚下的路，却照不透整座建筑的结构。

工具没有对错，只有适配与否；而所谓"优雅"或"原始"，往往只是我们面对复杂时情绪的投射。真正关键的，是在开放性与安全性、灵活性与性能之间，做出清醒的权衡，并为自己的选择负责。

最终，代码不只是逻辑的堆砌，更是判断的痕迹。我选择接受它的不完美，并用克制的拼接、谨慎的校验和明确的边界，为系统保留最后一道理性的防线。