MyBatis动态SQL在饿了么CPS系统的高效实践

1. 饿了么CPS系统的技术背景与需求分析

在本地生活服务领域，CPS（Cost Per Sale）系统作为电商平台的核心结算模块，承担着订单分佣、结算规则管理和数据统计等重要职责。饿了么作为国内领先的外卖平台，其CPS系统需要处理每天数千万级别的订单数据，这对系统的稳定性和数据处理能力提出了极高要求。

Java作为企业级应用开发的主流语言，在饿了么CPS系统中扮演着关键角色。而MyBatis作为轻量级的ORM框架，凭借其灵活的SQL控制能力和良好的性能表现，成为处理复杂业务逻辑的理想选择。特别是在以下典型场景中：

• 多维度佣金计算规则（如时段、商户类型、促销活动等）
• 跨表关联查询（订单主表、商户表、用户表、活动表等）
• 动态条件统计报表生成
• 批量结算数据处理

这些场景都高度依赖MyBatis的动态SQL和关联查询能力。以佣金计算为例，一个订单的最终佣金可能涉及10余个维度的条件判断，传统的静态SQL难以应对这种复杂度。

2. MyBatis动态SQL在CPS系统中的实战应用

2.1 基础动态标签使用技巧

MyBatis提供了<if>、<choose>、<when>、<otherwise>、<trim>、<where>、<set>等动态标签，在CPS系统中，这些标签的组合使用可以解决90%以上的条件查询需求。

xml复制<select id="queryCommissionRules" resultType="CommissionRule">
  SELECT * FROM commission_rule
  <where>
    <if test="merchantType != null">
      AND merchant_type = #{merchantType}
    </if>
    <if test="platformId != null">
      AND platform_id = #{platformId}
    </if>
    <choose>
      <when test="isSpecial != null and isSpecial">
        AND special_flag = 1
      </when>
      <otherwise>
        AND status = 1
      </otherwise>
    </choose>
  </where>
</select>

注意：<where>标签会自动处理前缀AND/OR，避免SQL语法错误。这是实际开发中最容易忽略但非常重要的细节。

2.2 动态SQL性能优化实践

在高并发的CPS系统中，动态SQL的性能优化至关重要。以下是我们在饿了么系统中总结的经验：

1. 避免过度动态化：对于高频查询，动态条件不宜超过5个，否则会导致SQL解析开销增大。我们通过将复杂规则拆分为多个查询来优化。

2. 合理使用<trim>：在批量插入场景下，<trim>比多个<if>更高效：

xml复制<insert id="batchInsert">
  INSERT INTO order_settlement
  <trim prefix="(" suffix=")" suffixOverrides=",">
    order_id, merchant_id,
    <if test="item.platformFee != null">platform_fee,</if>
    <if test="item.commission != null">commission,</if>
  </trim>
  VALUES
  <foreach collection="list" item="item" separator=",">
    <trim prefix="(" suffix=")" suffixOverrides=",">
      #{item.orderId}, #{item.merchantId},
      <if test="item.platformFee != null">#{item.platformFee},</if>
      <if test="item.commission != null">#{item.commission},</if>
    </trim>
  </foreach>
</insert>

3. 参数预处理：对于日期范围等常见条件，建议在Java层预处理后再传入Mapper，减少XML中的逻辑判断。

2.3 动态表名与字段处理

CPS系统经常需要按商户等级、地区等维度分表存储数据。MyBatis处理动态表名的正确姿势：

java复制@SelectProvider(type = SettlementSqlBuilder.class, method = "buildQuerySql")
List<Settlement> queryByTable(@Param("tableSuffix") String suffix, 
                             @Param("query") QueryCondition condition);

public class SettlementSqlBuilder {
    public String buildQuerySql(Map<String, Object> params) {
        String suffix = (String) params.get("tableSuffix");
        QueryCondition condition = (QueryCondition) params.get("query");
        
        return new SQL() {{
            SELECT("*");
            FROM("settlement_" + suffix);
            if (condition.getStartTime() != null) {
                WHERE("create_time >= #{query.startTime}");
            }
            // 其他条件...
        }}.toString();
    }
}

关键点：使用SQL Provider方式比在XML中使用${}更安全，能有效防止SQL注入。

3. 复杂关联查询的解决方案

3.1 一对一与一对多关联

CPS系统中最典型的关联场景是订单与结算明细的关系。MyBatis提供两种处理方式：

方式一：嵌套ResultMap

xml复制<resultMap id="orderWithDetails" type="Order">
  <id property="id" column="order_id"/>
  <result property="amount" column="order_amount"/>
  <collection property="settlements" ofType="Settlement">
    <id property="id" column="settlement_id"/>
    <result property="amount" column="settle_amount"/>
  </collection>
</resultMap>

<select id="getOrderWithDetails" resultMap="orderWithDetails">
  SELECT o.id as order_id, o.amount as order_amount,
         s.id as settlement_id, s.amount as settle_amount
  FROM orders o
  LEFT JOIN settlements s ON o.id = s.order_id
  WHERE o.id = #{orderId}
</select>

方式二：嵌套Select查询

xml复制<resultMap id="orderWithDetailsLazy" type="Order">
  <id property="id" column="id"/>
  <collection property="settlements" 
              select="selectSettlementsByOrderId"
              column="id"/>
</resultMap>

<select id="selectOrderWithDetailsLazy" resultMap="orderWithDetailsLazy">
  SELECT * FROM orders WHERE id = #{orderId}
</select>

<select id="selectSettlementsByOrderId" resultType="Settlement">
  SELECT * FROM settlements WHERE order_id = #{orderId}
</select>

性能对比：

• 嵌套ResultMap：单次查询，数据量大时可能产生笛卡尔积
• 嵌套Select：N+1查询问题，但支持懒加载

在饿了么CPS系统中，我们根据数据量选择方案：主表数据量小于1万时用嵌套ResultMap，大于1万时用嵌套Select+分页。

3.2 多对多关联的优化处理

商户与活动之间的多对多关系是CPS系统的典型场景。我们采用中间表+批量查询优化：

xml复制<resultMap id="merchantWithActivities" type="Merchant">
  <id property="id" column="id"/>
  <collection property="activities" ofType="Activity"
              select="batchSelectActivities"
              column="{merchantIds=id}"/>
</resultMap>

<select id="batchSelectActivities" resultType="Activity">
  SELECT a.* FROM activities a
  JOIN merchant_activity ma ON a.id = ma.activity_id
  WHERE ma.merchant_id IN 
  <foreach item="id" collection="merchantIds" open="(" separator="," close=")">
    #{id}
  </foreach>
</select>

这种批量查询方式将N+1问题转化为1+1，性能提升显著。实测在商户数5000+时，查询时间从15s降至300ms。

3.3 分页关联查询的陷阱与解决方案

CPS系统的报表查询经常需要分页+关联，这里有个经典陷阱：

xml复制<!-- 错误示例 -->
<select id="queryPagedOrders" resultMap="orderWithDetails">
  SELECT o.*, s.* FROM orders o
  LEFT JOIN settlements s ON o.id = s.order_id
  LIMIT #{offset}, #{pageSize}
</select>

这种写法会导致分页不准（主表记录数与实际不符）。正确做法是先分页查询主表ID，再关联：

xml复制<select id="queryPagedOrders" resultMap="orderWithDetails">
  SELECT o.*, s.* FROM (
    SELECT id FROM orders
    WHERE create_time BETWEEN #{start} AND #{end}
    LIMIT #{offset}, #{pageSize}
  ) temp
  JOIN orders o ON temp.id = o.id
  LEFT JOIN settlements s ON o.id = s.order_id
</select>

在饿了么系统中，我们进一步优化为内存分页：先查询符合条件的ID列表（带分页参数），再用IN查询获取完整数据。

4. MyBatis在CPS系统中的高级技巧

4.1 类型处理器定制开发

CPS系统中有大量金额计算，我们自定义了BigDecimal类型处理器避免精度丢失：

java复制public class MoneyTypeHandler extends BaseTypeHandler<BigDecimal> {
    @Override
    public void setNonNullParameter(PreparedStatement ps, int i, 
                                  BigDecimal parameter, JdbcType jdbcType) {
        ps.setLong(i, parameter.movePointRight(4).longValue());
    }

    @Override
    public BigDecimal getNullableResult(ResultSet rs, String columnName) {
        long value = rs.getLong(columnName);
        return BigDecimal.valueOf(value).movePointLeft(4);
    }
    // 其他重载方法...
}

配置方式：

xml复制<typeHandlers>
  <typeHandler handler="com.eleme.cps.MoneyTypeHandler" 
              javaType="java.math.BigDecimal"/>
</typeHandlers>

这个处理器将金额以整数形式存储（精确到0.0001元），解决了Java浮点数计算精度问题。

4.2 插件开发实战

我们开发了多个MyBatis插件优化CPS系统性能：

1. SQL执行时间监控插件

java复制@Intercepts({
  @Signature(type= Executor.class, method="update", 
            args={MappedStatement.class,Object.class}),
  @Signature(type= Executor.class, method="query",
            args={MappedStatement.class,Object.class,RowBounds.class,ResultHandler.class})
})
public class PerformanceInterceptor implements Interceptor {
    private static final long SLOW_QUERY_THRESHOLD = 500; //ms
    
    @Override
    public Object intercept(Invocation invocation) {
        long start = System.currentTimeMillis();
        try {
            return invocation.proceed();
        } finally {
            long cost = System.currentTimeMillis() - start;
            if (cost > SLOW_QUERY_THRESHOLD) {
                MappedStatement ms = (MappedStatement) invocation.getArgs()[0];
                log.warn("Slow SQL detected: {} - {}ms", 
                        ms.getId(), cost);
            }
        }
    }
}

2. 分页自动优化插件

java复制public Object intercept(Invocation invocation) {
    Object[] args = invocation.getArgs();
    RowBounds rb = (RowBounds) args[2];
    if (rb != RowBounds.DEFAULT) {
        // 改写SQL添加分页逻辑
        MappedStatement ms = (MappedStatement) args[0];
        BoundSql boundSql = ms.getBoundSql(args[1]);
        String newSql = boundSql.getSql() + 
                       " LIMIT " + rb.getOffset() + "," + rb.getLimit();
        resetSql(ms, boundSql, newSql);
    }
    return invocation.proceed();
}

这些插件在饿了么CPS系统中帮助我们发现并优化了数百个慢查询，平均响应时间降低了40%。

4.3 二级缓存与分布式一致性

CPS系统的结算规则数据读多写少，适合使用缓存。但直接启用MyBatis二级缓存会导致分布式环境下的数据不一致。我们的解决方案：

1. 使用Redis实现自定义缓存：

java复制public class RedisCache implements Cache {
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private final String id;
    private final RedisTemplate<String, Object> redisTemplate;
    
    public Object getObject(Object key) {
        try {
            lock.readLock().lock();
            return redisTemplate.opsForValue().get(key.toString());
        } finally {
            lock.readLock().unlock();
        }
    }
    // 其他方法实现...
}

2. 配置缓存策略：

xml复制<cache type="com.eleme.cps.RedisCache"
      eviction="LRU"
      flushInterval="60000"
      size="1024"/>

3. 关键业务操作添加缓存清除：

java复制public void updateCommissionRule(CommissionRule rule) {
    ruleMapper.update(rule);
    // 手动清除相关缓存
    redisTemplate.delete("com.eleme.mapper.CommissionRuleMapper.queryActiveRules");
}

这套方案在保证性能的同时，将缓存不一致时间窗口控制在1分钟内，完全满足CPS业务需求。

5. 典型问题排查与性能优化

5.1 N+1查询问题深度解决

虽然3.1节提到了基本解决方案，但在CPS系统的复杂场景下，我们还需要更多手段：

方案一：批量嵌套查询

xml复制<select id="batchQueryOrders" resultMap="orderWithDetails">
  SELECT * FROM orders WHERE id IN
  <foreach item="id" collection="ids" open="(" separator="," close=")">
    #{id}
  </foreach>
</select>

<select id="batchQuerySettlements" resultType="Settlement">
  SELECT * FROM settlements WHERE order_id IN
  <foreach item="id" collection="orderIds" open="(" separator="," close=")">
    #{id}
  </foreach>
</select>

方案二：使用@MapKey注解

java复制@MapKey("orderId")
Map<Long, List<Settlement>> selectSettlementsByOrderIds(@Param("orderIds") List<Long> orderIds);

方案三：ResultMap嵌套+集合分组

java复制public class OrderResultHandler implements ResultHandler<Order> {
    private Map<Long, Order> orderMap = new HashMap<>();
    
    @Override
    public void handleResult(ResultContext<? extends Order> context) {
        Order order = context.getResultObject();
        orderMap.put(order.getId(), order);
    }
    
    public List<Order> getOrders() {
        return new ArrayList<>(orderMap.values());
    }
}

// 使用方式
OrderResultHandler handler = new OrderResultHandler();
sqlSession.select("queryOrdersWithDetails", param, handler);
List<Order> orders = handler.getOrders();

在饿了么CPS系统中，我们根据查询复杂度选择方案：简单查询用方案一，中等复杂度用方案二，超复杂报表用方案三。

5.2 大数据量导出优化

CPS系统每天需要导出数百万条结算记录，我们采用流式查询+分片处理：

java复制@Select("SELECT * FROM settlements WHERE create_time BETWEEN #{start} AND #{end}")
@Options(resultSetType = ResultSetType.FORWARD_ONLY, 
         fetchSize = 1000)
@ResultType(Settlement.class)
void exportSettlements(@Param("start") Date start, 
                      @Param("end") Date end,
                      ResultHandler<Settlement> handler);

// 调用示例
settlementMapper.exportSettlements(startDate, endDate, context -> {
    Settlement settlement = context.getResultObject();
    // 写入文件或发送到消息队列
    writeToCSV(settlement);
});

关键配置：

• ResultSetType.FORWARD_ONLY：只进游标，减少内存占用
• fetchSize=1000：每次从数据库获取1000条
• 使用ResultHandler逐条处理，避免内存溢出

实测该方案可稳定处理千万级数据导出，内存占用保持在50MB以内。

5.3 动态SQL与预编译语句的平衡

MyBatis动态SQL最终会生成预编译语句，但过多的动态条件会导致：

1. 数据库需要缓存大量不同的预处理语句
2. 每次执行都需要重新生成执行计划

我们的优化策略：

1. 固定常见查询模式

xml复制<sql id="commonCommissionConditions">
  <if test="status != null">AND status = #{status}</if>
  <if test="merchantType != null">AND merchant_type = #{merchantType}</if>
</sql>

<select id="queryByPage" resultType="CommissionRule">
  SELECT * FROM commission_rule
  <where>
    <include refid="commonCommissionConditions"/>
  </where>
  LIMIT #{offset}, #{pageSize}
</select>

2. 使用SQL Builder统一生成逻辑

java复制public class CommissionSqlBuilder {
    public static String buildQuerySql(Map<String, Object> params) {
        return new SQL() {{
            SELECT("*");
            FROM("commission_rule");
            if (params.get("status") != null) {
                WHERE("status = #{status}");
            }
            // 其他条件...
        }}.toString();
    }
}

3. 启用MyBatis配置

xml复制<settings>
  <setting name="defaultScriptingLanguage" value="velocity"/>
  <setting name="useActualParamName" value="false"/>
</settings>

这些措施使我们的预处理语句缓存命中率从60%提升到95%，数据库CPU负载下降30%。

6. 实际案例：佣金计算服务优化

6.1 原始方案与问题

饿了么CPS最初的佣金计算采用简单的一对一查询：

java复制public BigDecimal calculateCommission(Long orderId) {
    Order order = orderMapper.selectById(orderId);
    List<CommissionRule> rules = ruleMapper.queryRules(order.getMerchantId());
    
    BigDecimal commission = BigDecimal.ZERO;
    for (CommissionRule rule : rules) {
        if (rule.match(order)) {
            commission = commission.add(rule.calculate(order));
        }
    }
    return commission;
}

当QPS达到500+时，出现：

1. 数据库连接池耗尽
2. 平均响应时间超过1秒
3. 频繁Full GC

6.2 优化方案设计与实现

第一步：规则预加载

java复制@Scheduled(fixedRate = 60000)
public void refreshRules() {
    List<CommissionRule> allRules = ruleMapper.queryAllActiveRules();
    // 按商户分组缓存
    ruleCache = allRules.stream()
        .collect(Collectors.groupingBy(CommissionRule::getMerchantId));
}

第二步：批量查询优化

java复制public Map<Long, BigDecimal> batchCalculate(List<Long> orderIds) {
    // 1. 批量查询订单
    List<Order> orders = orderMapper.batchSelect(orderIds);
    
    // 2. 按商户分组
    Map<Long, List<Order>> merchantOrders = orders.stream()
        .collect(Collectors.groupingBy(Order::getMerchantId));
    
    // 3. 并行计算
    return merchantOrders.entrySet().parallelStream()
        .flatMap(entry -> {
            List<CommissionRule> rules = ruleCache.get(entry.getKey());
            return entry.getValue().stream()
                .map(order -> calculateSingle(order, rules));
        })
        .collect(Collectors.toMap(
            Pair::getOrderId, 
            Pair::getCommission));
}

第三步：MyBatis配置调优

xml复制<settings>
  <setting name="defaultExecutorType" value="BATCH"/>
  <setting name="jdbcTypeForNull" value="NULL"/>
  <setting name="aggressiveLazyLoading" value="false"/>
</settings>

6.3 优化效果对比

这个案例充分展示了合理使用MyBatis动态SQL和关联查询技巧对系统性能的巨大影响。