Mybatis一对多查询性能优化实战

1. Mybatis+MySQL一对多查询问题解析

最近在重构一个老项目的订单模块时，遇到了典型的Mybatis一对多查询性能问题。当订单明细数据量达到万级时，页面加载需要近10秒，这显然不可接受。通过分析发现，问题出在Mybatis的ResultMap配置和Collection标签使用上。

一对多关系是数据库设计中常见场景，比如订单与订单项、博客与评论等。Mybatis提供了两种处理方式：嵌套查询（Nested Select）和嵌套结果（Nested Results）。前者会产生N+1查询问题，后者虽然单次查询但可能返回大量冗余数据。理解它们的差异是优化查询性能的关键。

2. 核心实现方案对比

2.1 嵌套查询方式

xml复制<resultMap id="orderResultMap" type="Order">
    <id property="id" column="id"/>
    <collection property="items" ofType="OrderItem" 
        select="selectItemsByOrderId" column="id"/>
</resultMap>

<select id="selectOrderWithItems" resultMap="orderResultMap">
    SELECT * FROM orders WHERE id = #{id}
</select>

<select id="selectItemsByOrderId" resultType="OrderItem">
    SELECT * FROM order_items WHERE order_id = #{orderId}
</select>

这种方式直观清晰，但存在严重性能问题：

• 查询订单1次
• 查询每个订单的明细N次
• 总查询次数=1+N（N=订单数量）

实际测试：查询100个订单（每个订单平均5个明细），数据库交互达到501次，耗时约1200ms

2.2 嵌套结果方式

xml复制<resultMap id="orderResultMap" type="Order">
    <id property="id" column="o_id"/>
    <result property="orderNo" column="o_no"/>
    <collection property="items" ofType="OrderItem">
        <id property="id" column="i_id"/>
        <result property="productName" column="i_product"/>
    </collection>
</resultMap>

<select id="selectOrderWithItems" resultMap="orderResultMap">
    SELECT 
        o.id as o_id, o.order_no as o_no,
        i.id as i_id, i.product_name as i_product
    FROM orders o
    LEFT JOIN order_items i ON o.id = i.order_id
    WHERE o.id = #{id}
</select>

这种方式通过单次JOIN查询获取所有数据，但需要注意：

1. 必须使用别名避免列名冲突
2. 结果集会包含重复的订单主表信息
3. 大数据量时网络传输压力较大

实测相同场景：数据库交互1次，耗时约200ms，但返回数据量是前者的3倍

3. 深度优化方案

3.1 分页查询优化

对于大数据量场景，建议结合分页使用嵌套结果方式：

java复制@Select("SELECT o.*, i.* FROM orders o " +
        "LEFT JOIN order_items i ON o.id = i.order_id " +
        "WHERE o.user_id = #{userId} " +
        "LIMIT #{offset}, #{pageSize}")
@Results({
    @Result(property = "id", column = "o_id"),
    @Result(property = "items", column = "o_id",
            many = @Many(select = "selectItemsByOrderId"))
})
List<Order> selectUserOrdersWithItems(@Param("userId") Long userId,
                                    @Param("offset") int offset,
                                    @Param("pageSize") int pageSize);

这种混合方案：

1. 主查询使用JOIN+分页减少数据传输量
2. 明细查询仍用嵌套方式避免重复数据
3. 总查询次数=1+1（非1+N）

3.2 延迟加载配置

在mybatis-config.xml中启用全局延迟加载：

xml复制<settings>
    <setting name="lazyLoadingEnabled" value="true"/>
    <setting name="aggressiveLazyLoading" value="false"/>
</settings>

然后为collection添加fetchType="lazy"：

xml复制<collection property="items" ofType="OrderItem" 
    select="selectItemsByOrderId" column="id"
    fetchType="lazy"/>

这样只有在访问order.getItems()时才会触发明细查询。

4. 实战问题排查

4.1 列名冲突问题

常见错误日志：

code复制Cause: org.apache.ibatis.executor.ExecutorException: 
No constructor found in Order matching [java.lang.Long, java.lang.String...]

解决方案：

1. 为所有列添加明确前缀别名
2. 确保ResultMap中column与SQL别名一致
3. 使用<id>标记主键列

4.2 N+1查询问题

通过日志发现多次简单查询：

code复制==> Preparing: SELECT * FROM order_items WHERE order_id = ?
==> Parameters: 1(Long)
<== Total: 3
==> Preparing: SELECT * FROM order_items WHERE order_id = ?
==> Parameters: 2(Long) 

优化方案：

1. 改用嵌套结果方式
2. 或开启MyBatis二级缓存
3. 或使用@BatchSelect注解（MyBatis-Spring扩展）

4.3 大数据量内存溢出

当查询结果超过10万条时可能出现OOM，解决方法：

1. 添加分页参数
2. 使用ResultHandler流式处理
3. 设置fetchSize减少内存占用

java复制@Select("SELECT * FROM large_table")
@Options(fetchSize = 100)
void streamLargeData(ResultHandler<LargeData> handler);

5. 高级技巧

5.1 动态字段控制

使用<if>标签实现按需查询：

xml复制<resultMap id="orderResultMap" type="Order">
    <id property="id" column="id"/>
    <collection property="items" ofType="OrderItem" 
        select="selectItemsByOrderId" column="{orderId=id,fields=itemFields}"/>
</resultMap>

<select id="selectItemsByOrderId" resultType="OrderItem">
    SELECT 
    <if test="fields != null and fields != ''">
        ${fields}
    </if>
    <if test="fields == null or fields == ''">
        *
    </if>
    FROM order_items WHERE order_id = #{orderId}
</select>

注意：${}有SQL注入风险，应确保参数可信或改用OGNL表达式

5.2 多级嵌套查询

处理三级关联（如订单→明细→产品）：

xml复制<resultMap id="orderResultMap" type="Order">
    <collection property="items" resultMap="itemResultMap"/>
</resultMap>

<resultMap id="itemResultMap" type="OrderItem">
    <association property="product" select="selectProductById" column="product_id"/>
</resultMap>

建议超过两级关联改用JOIN查询，避免性能劣化。

5.3 自定义结果处理器

对于特殊数据结构，可以实现ResultHandler：

java复制public class OrderResultHandler implements ResultHandler<Order> {
    private Map<Long, Order> orderMap = new LinkedHashMap<>();
    
    @Override
    public void handleResult(ResultContext<? extends Order> context) {
        Order order = context.getResultObject();
        if(!orderMap.containsKey(order.getId())){
            orderMap.put(order.getId(), order);
        }
        // 处理明细数据...
    }
}

6. 性能对比数据

通过JMeter压测（100并发）：

7. 架构思考

在微服务架构下，一对多查询更建议：

1. 订单服务只提供基础订单数据
2. 通过Feign调用商品服务获取商品详情
3. 前端或API网关聚合数据

这样避免了复杂的JOIN查询，各服务独立演进。Mybatis的一对多处理更适合单体应用或数据量不大的场景。