在Java持久层框架的选择上，JPA（及其实现如Hibernate）与MyBatis的争论从未停止。JPA的优势在于快速开发、对象化思维和标准规范，但在面对复杂多变的查询场景时，我们常常会感到束手束脚。这时，MyBatis的真正威力——尤其是其动态SQL能力——就显现出来了。

这篇博客不是要贬低JPA，而是要展示当业务逻辑超出简单的CRUD范畴时，如何通过MyBatis的工程化实践，优雅、高效地解决复杂查询问题。

一、为什么是MyBatis？从一个日常场景说起

假设你正在开发一个电商后台的“订单管理”页面。前端传过来的查询条件可能包括：

• 订单号（精确）
• 用户ID（精确）
• 订单状态（多选）
• 商品名称（模糊）
• 创建时间范围（起始-结束）
• 排序字段（按时间、金额等）

如果用JPA的Specification或QueryDSL来写，代码会迅速变得复杂且难以阅读。更重要的是，当查询条件极度复杂时，你可能会被迫使用@Query手写JPQL，这又回到了字符串拼接的老路，失去了类型安全，并且难以动态化。

而MyBatis从一开始就为此而生。它的核心理念是：SQL是专家的事，框架负责把参数映射好，把结果映射好，中间的过程交给专家（也就是你）来把控。

二、动态SQL基础：不仅仅是<if>标签

大家都知道MyBatis有<if>标签，但工程化实践远不止于此。

1. <where> 标签的智慧：告别丑陋的 1=1

新手常这样写：

SELECT * FROM orders
WHERE 1=1
<if test="orderNo != null">
    AND order_no = #{orderNo}
</if>
<if test="status != null">
    AND status = #{status}
</if>

1=1是为了避免所有条件都为空时出现WHERE AND的语法错误。但这不够优雅。

工程化写法：使用 <where>

SELECT * FROM orders
<where>
    <if test="orderNo != null">
        AND order_no = #{orderNo}
    </if>
    <if test="statusList != null and statusList.size() > 0">
        AND status IN
        <foreach collection="statusList" item="status" open="(" close=")" separator=",">
            #{status}
        </foreach>
    </if>
    <if test="productName != null and productName != ''">
        AND EXISTS (
            SELECT 1 FROM order_item oi JOIN product p ON oi.product_id = p.id
            WHERE oi.order_id = orders.id AND p.name LIKE CONCAT('%', #{productName}, '%')
        )
    </if>
</where>

<where>标签的智能之处在于：

• 只有当子元素有返回内容时，才插入WHERE关键字。
• 会自动剔除掉子句开头的AND或OR。 这样你就不用担心第一个条件前多一个AND了。

2. <choose> 标签：实现“多选一”的逻辑

业务场景：优先按订单号查，如果订单号没给，就按用户ID查，如果都没给，就查最近一周的订单。

<select id="selectOrders" resultMap="orderResultMap">
    SELECT * FROM orders
    <where>
        <choose>
            <when test="orderNo != null">
                order_no = #{orderNo}
            </when>
            <when test="userId != null">
                AND user_id = #{userId}
            </when>
            <otherwise>
                AND created_time >= DATE_SUB(NOW(), INTERVAL 7 DAY)
            </otherwise>
        </choose>
        <if test="status != null">
            AND status = #{status} <!-- 其他条件可以继续叠加 -->
        </if>
    </where>
</select>

<choose>就像Java里的if-else if-else，保证了分支的唯一性，让查询逻辑更清晰。

3. <sql> 与 <include>：实现SQL片段复用

这是工程化的关键一步。当多个查询语句需要复用相同的列列表或复杂的JOIN条件时，使用它们可以避免重复代码。

定义可复用的SQL片段：

<!-- 在mapper.xml顶部定义 -->
<sql id="orderBaseColumns">
    id, order_no, user_id, total_amount, status, created_time
</sql>

<sql id="orderWithItemAndProduct">
    o.id, o.order_no, o.user_id, oi.product_id, oi.quantity, p.name as product_name
    FROM orders o
    LEFT JOIN order_item oi ON o.id = oi.order_id
    LEFT JOIN product p ON oi.product_id = p.id
</sql>

在查询中引用：

<!-- 简单的查询 -->
<select id="selectSimpleOrder" resultMap="simpleOrderMap">
    SELECT
    <include refid="orderBaseColumns"/>
    FROM orders
    WHERE id = #{id}
</select>

<!-- 复杂的联表查询 -->
<select id="selectOrderDetail" resultMap="detailOrderMap">
    SELECT
    <include refid="orderWithItemAndProduct"/>
    WHERE o.id = #{id}
</select>

这样做的好处是：一处修改，处处生效。比如要给订单加一个update_time字段，你只需要修改orderBaseColumns这个片段。

三、高级场景：当查询复杂到令人头疼时

场景：同一个字段，根据不同的查询类型进行不同方式的匹配。

比如，商品搜索：

• 类型为1时，按商品名称精确匹配。
• 类型为2时，按商品名称前缀匹配（如‘手机%’）。
• 类型为3时，按商品名称模糊匹配（如‘%手机%’）。

笨拙的写法：

<if test="type == 1">
    AND name = #{keyword}
</if>
<if test="type == 2">
    AND name LIKE CONCAT(#{keyword}, '%')
</if>
<if test="type == 3">
    AND name LIKE CONCAT('%', #{keyword}, '%')
</if>

工程化写法：使用<bind>标签预先计算

<select id="searchProducts" resultMap="productMap">
    <bind name="pattern" value="@com.example.util.SearchPatternBuilder@build(type, keyword)"/>
    SELECT * FROM product
    <where>
        <if test="pattern != null">
            AND name LIKE #{pattern}
        </if>
    </where>
</select>

然后，创建一个工具类：

public class SearchPatternBuilder {
    public static String build(Integer type, String keyword) {
        if (type == null || keyword == null) return null;
        switch (type) {
            case 1: return keyword; // 精确匹配，在SQL中直接用 =，这里只是示例
            case 2: return keyword + "%";
            case 3: return "%" + keyword + "%";
            default: return null;
        }
    }
}

<bind>标签允许你在OWNL表达式内创建一个变量，这个变量可以在后续的SQL中使用。这可以将复杂的判断逻辑移到Java代码中，保持XML的简洁。

四、结果映射的工程化：<resultMap>的威力

MyBatis的<resultMap>是其另一大杀器，可以处理任意复杂的对象关系。

场景：查询订单及其所有订单项（一对多）

<!-- 1. 定义订单的ResultMap -->
<resultMap id="OrderWithItemsResultMap" type="com.example.entity.Order" autoMapping="true">
    <id column="id" property="id"/>
    <!-- 其他字段用autoMapping="true"自动映射（列名与属性名一致时） -->
    
    <!-- 2. 处理一对多关系：订单项集合 -->
    <collection property="itemList" ofType="com.example.entity.OrderItem" autoMapping="true">
        <id column="item_id" property="id"/> <!-- 明确指定订单项的主键 -->
        <!-- 订单项内部还可以关联商品对象（多对一） -->
        <association property="product" javaType="com.example.entity.Product" autoMapping="true">
            <id column="product_id" property="id"/>
            <result column="product_name" property="name"/>
        </association>
    </collection>
</resultMap>

<!-- 3. 使用ResultMap的查询 -->
<select id="selectOrderWithItems" resultMap="OrderWithItemsResultMap">
    SELECT
        o.*,
        oi.id as item_id, oi.quantity, oi.price,
        p.id as product_id, p.name as product_name
    FROM orders o
    LEFT JOIN order_item oi ON o.id = oi.order_id
    LEFT JOIN product p ON oi.product_id = p.id
    WHERE o.id = #{orderId}
</select>

通过一个复杂的<resultMap>，MyBatis可以帮你将一条SQL查询出来的扁平化结果，自动组装成嵌套的、具有层次结构的对象树（Order -> List<OrderItem> -> Product）。这避免了经典的“N+1”查询问题（即先查订单，再循环查每个订单的订单项）。

五、超越XML：当动态SQL复杂到XML也难以维护时

有时，动态条件复杂到连XML标签都显得臃肿不堪。这时，我们可以回归Java的怀抱。

使用MyBatis Provider注解（如@SelectProvider）

// 1. 创建一个Provider类
public class OrderSqlProvider {
    public String selectOrdersByComplexCondition(final Map<String, Object> params) {
        return new SQL() {{
            SELECT("o.*, u.username");
            FROM("orders o");
            INNER_JOIN("user u ON o.user_id = u.id");
            
            // 复杂的动态逻辑用纯Java代码编写
            if (params.get("orderNo") != null) {
                WHERE("o.order_no = #{orderNo}");
            }
            
            if (params.get("statusList") != null) {
                @SuppressWarnings("unchecked")
                List<String> statusList = (List<String>) params.get("statusList");
                if (!statusList.isEmpty()) {
                    String inClause = statusList.stream()
                            .map(s -> "'" + s + "'") // 注意防SQL注入，这里只是示例，实际应用参数化
                            .collect(Collectors.joining(", "));
                    WHERE("o.status IN (" + inClause + ")");
                }
            }
            // ... 更多复杂逻辑
            ORDER_BY("o.created_time DESC");
        }}.toString();
    }
}

// 2. 在Mapper接口中使用
public interface OrderMapper {
    @SelectProvider(type = OrderSqlProvider.class, method = "selectOrdersByComplexCondition")
    List<Order> selectByComplexCondition(@Param("orderNo") String orderNo, 
                                         @Param("statusList") List<String> statusList);
}

使用SQL这个Builder类，你可以用面向对象的方式构建SQL语句。它的优势在于：

• 强大的逻辑处理能力：你可以使用if-else、switch、for循环等所有Java特性。
• 类型安全：IDE会给你代码提示和编译期检查。
• 易于重构：可以轻松地将公共部分提取成方法。

总结：MyBatis工程化的核心思想

经过这些实践，我们可以看到MyBatis在复杂查询场景下的核心优势：

1. 声明式与命令式的完美结合：简单的CRUD用注解或简单的XML，复杂的查询用强大的动态SQL，各取所长。
2. SQL的可控性与透明度：你永远知道最终执行的SQL是什么样子，便于性能调优。
3. 极致的灵活性：从简单的<if>标签到完整的Java代码构建SQL，MyBatis提供了从低到高各种复杂度的解决方案。
4. 面向数据库专家：它不试图隐藏SQL的复杂性，而是为熟悉SQL的开发者提供最顺手的工具。

当你的项目从“简单业务”走向“复杂业务”时，当你的查询条件从固定不变走向千变万化时，MyBatis这种“把SQL交还给你”的哲学，反而成为一种强大的解放。它要求你成为SQL的专家，但回报给你的是对数据操作的绝对控制力和极致的性能表现。这，就是MyBatis在复杂查询领域能够“超越JPA”的根本原因。