MyBatis关联查询延迟加载实战案例

在MyBatis开发中，单表查询用resultType就能轻松搞定。但一旦遇到需要关联查询的场景，比如一个用户对应多个订单，或者反过来一个订单对应一个用户，事情就变得复杂了。特别是当性能成为考量因素时，resultMap配合延迟加载就成了必须掌握的核心技能。

一、核心基础概念

1. 业务场景：一对多关系

最经典的例子莫过于用户和订单的关系：一个用户（一）可以拥有多个订单（多），而一个订单（多）只属于一个用户（一）。

这种关系映射到Ja va实体类，通常是这样的结构：

// 用户实体（一的一方）
@Data
public class User {
    private Integer id;
    private String username;
    // 一对多：存放当前用户的所有订单
    private List orderList;
}
// 订单实体（多的一方）
@Data
public class Order {
    private Integer id;
    private String orderNo;
    // 多对一：存放订单所属的用户
    private User user;
}

2. 立即加载 VS 延迟加载（懒加载）

性能优化的核心，就在于理解这两种加载方式的区别，这也是配置fetchType="lazy"的意义所在。

简单来说，延迟加载就是按需加载，用不到的数据绝不查询！

二、为什么要写 resultMap？（关联查询专用）

1. 单表查询

日常的单表查询，比如只查用户或者只查订单，用resultType就能一行代码搞定，完全不需要复杂的配置。

    select * from tb_user where id = #{id}

✅ 适用场景非常明确：纯单表查询，无任何关联关系。

2. 必须用复杂配置的场景

但当需求升级，变成“查询主数据，并且希望关联数据能按需加载”时，情况就不同了。MyBatis有明确规定：要实现一对多或一对一的关联查询，并且要启用延迟加载，就必须使用 resultMap 来配置。这是框架的固定语法，没有捷径。

三、一对一延迟加载（association 标签）

一对一场景，比如订单表关联用户表（一个订单只属于一个用户），MyBatis通过association标签来实现延迟加载。

1. 一对一核心配置

    
    
        
        
        
        
        
    
    
    
        select * from tb_order where id = #{id}
    

✨ association 标签5大核心属性

1. property：实体类中关联对象属性名（对应Order类中的user属性）。
2. ja vaType：关联对象的实体类型。
3. select：延迟加载时需要调用的查询方法全路径。
4. column：传递给上述子查询的参数（通常是订单表中的user_id字段）。
5. fetchType="lazy"：这是开启一对一延迟加载的关键。

四、一对多延迟加载（collection 标签）

    
    
        
        
        
        
        
        
        
    
    
    
        select * from tb_user where id = #{id}
    

✨ collection 标签5大核心属性

这是一对多配置的灵魂，记住这5个属性，基本就不会写错了：

1. property：实体类中集合属性的名称（必须和User类中的orderList属性名完全一致）。
2. ofType：集合中存储的实体类型。
3. select：延迟加载时需要执行的子查询方法全路径。
4. column：传递给子查询的参数列（通常是用户id）。
5. fetchType="lazy"：开启延迟加载（默认是立即加载）。

五、完整实战代码

1. MyBatis全局配置（开启延迟加载总开关）

这里有两个关键配置需要理解：

① lazyLoadingEnabled（总开关）

作用：控制是否开启延迟加载。
默认值：false，即关闭延迟加载，默认使用立即加载。
通俗点说，如果这里是false，查询主数据时会直接把所有关联数据一起查出来，不管你是否马上用到。

② aggressiveLazyLoading（触发方式）

作用：控制延迟加载的触发条件。
默认值：false。
需要注意的是，只有总开关lazyLoadingEnabled设置为true时，这个配置才生效。
- 如果设为true：调用对象的任何方法（比如toString()、equals()或普通的getter方法）都可能触发关联数据的加载。
- 如果设为false：只有明确调用了关联属性自身的getter方法时，才会触发加载。这才是最标准、最符合预期的“懒加载”行为。

2. 子查询Mapper配置

无论是association还是collection，其select属性指向的子查询方法，都必须在对应的Mapper文件中明确定义。

    
    
        select * from tb_order where user_id = #{userId}
    

3. Mapper接口

// UserMapper
public interface UserMapper {
    User selectById(Integer id);
}
// OrderMapper
public interface OrderMapper {
    List findByUid(Integer userId);
    Order selectById(Integer id);
}

六、延迟加载执行流程

1. 一对一执行流程

@Test
public void testOneToOne(){
    // 1. 仅查询订单：只执行1条SQL → select * from tb_order where id=1
    Order order = orderMapper.selectById(1);
    System.out.println("订单编号：" + order.getOrderNo());
    // 2. 调用user：触发一对一延迟加载，查询用户信息
    System.out.println("订单所属用户：" + order.getUser());
}

2. 一对多执行流程

@Test
public void testLazyLoad(){
    // 1. 仅查询用户：只执行1条SQL → select * from tb_user where id=1
    User user = userMapper.selectById(1);
    System.out.println("查询到用户：" + user.getUsername());
    // 2. 未使用订单数据：不执行订单查询SQL
    // 3. 调用orderList：触发延迟加载，执行订单SQL → select * from tb_order where user_id=1
    System.out.println("用户订单：" + user.getOrderList());
}

可以看到，按需加载被完美实现了。

七、注意事项

1. 忘记开启全局延迟加载
   全局开关 lazyLoadingEnabled（默认是 false）控制着所有未显式设置 fetchType 的关联查询。而局部属性 fetchType="lazy" 可以让单个关联独立实现延迟加载，不受全局开关影响。
2. 子查询方法不存在或路径写错
   select属性必须填写全限定名（即包含命名空间的方法全路径），因为这里调用的是另一个Mapper文件中的方法。
3. 实体类属性名不匹配
   配置中的property属性必须和实体类中定义的属性名完全一致，大小写敏感。
4. 标签区分
   一对多用collection，一对一用association，两者不可混用。

八、延迟加载的优势

• 提升性能：有效避免查询当前业务逻辑不需要的关联数据，显著减少数据库压力。
• 解决N+1问题：在查询主数据时，不会自动触发关联数据的查询，从而避免了N+1查询问题。
• 灵活适配业务：当业务只需要主数据时，不会产生冗余的SQL查询。
• 通用适配：配置方案同时支持一对多、一对一等多种关联场景。

九、总结

1. 单表查询：使用resultType，无需任何复杂配置，这是日常开发的主流。
2. 一对一关联：必须使用resultMap + association组合。
3. 一对多关联：必须使用resultMap + collection组合。
4. 延迟加载核心：关键在于fetchType="lazy"配置，配合全局开关，实现真正的按需加载。
5. 核心标签：association（用于一对一）和collection（用于一对多），两者的语法结构高度一致，主要区别在于标签名和表示集合元素类型的属性（ja vaType vs ofType）。