在MyBatis框架开发中，单表查询使用resultType即可轻松完成数据映射。然而，当面临复杂的关联查询场景时，例如查询用户及其所有订单，或者查询订单及其所属用户，性能优化便成为关键考量。此时，掌握resultMap与延迟加载的配合使用，是提升MyBatis应用性能的核心技能。
一、核心基础概念
1. 业务场景：一对多关系
用户与订单的关系是经典的一对多模型：一个用户（一）可以拥有多个订单（多），同时一个订单（多）必然属于一个用户（一）。
这种关系映射到Java实体类，通常采用以下结构：
// 用户实体（一的一方）
@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"的根本目的。
| 加载方式 | 含义 | 优缺点 |
|---|---|---|
| 立即加载 | 执行主查询时，同步执行所有关联数据的查询 | 实现简单；易产生冗余查询，性能开销大 |
| 延迟加载 | 执行主查询时仅查询主表数据，仅在代码访问关联属性时才触发查询 | 有效减少冗余SQL，性能优异；需要额外配置 |
简而言之，延迟加载实现了按需查询，有效避免了不必要的数据加载！
二、为什么必须使用 resultMap？（关联查询专用）
1. 单表查询
对于常规的单表查询，例如仅查询用户信息或订单信息，使用resultType即可直接完成字段映射，无需复杂配置。
✅ 适用场景非常明确：纯单表查询，不涉及任何关联关系。
2. 必须使用复杂配置的场景
当业务需求升级，需要“查询主数据，并希望关联数据能智能地按需加载”时，情况就不同了。MyBatis框架明确规定：要实现一对一或一对多的关联查询，并启用延迟加载功能，必须通过 resultMap 进行详细配置。这是框架的固定语法规则，没有替代方案。
三、一对一延迟加载（association 标签）
在一对一场景中，例如订单关联其所属用户（一个订单对应一个用户），MyBatis通过association标签来实现延迟加载。
1. 一对一核心配置
✨ association 标签5大核心属性详解
property：实体类中关联对象属性名（对应Order类中的user属性）。ja vaType：关联对象的实体类型。select：延迟加载时需要调用的查询方法全限定名。column：传递给上述子查询的参数（通常是订单表中的user_id字段）。fetchType="lazy"：这是开启一对一延迟加载的关键属性。
四、一对多延迟加载（collection 标签）
✨ collection 标签5大核心属性详解
这是一对多配置的核心，掌握这5个属性即可应对大多数场景：
property：实体类中集合属性的名称（必须与User类中的orderList属性名完全一致）。ofType：集合中存储的元素实体类型。select：延迟加载时需要执行的子查询方法全路径。column：传递给子查询的参数列（通常是用户id）。fetchType="lazy"：显式开启延迟加载（默认值为立即加载）。
五、完整实战代码配置
1. MyBatis全局配置（开启延迟加载总开关）
理解这两个关键配置至关重要：
① lazyLoadingEnabled（总开关）
作用：全局控制是否启用延迟加载机制。
默认值：false，即关闭延迟加载，所有关联查询默认采用立即加载。
通俗解释：若设为false，查询主数据时会一次性加载所有关联数据，无论业务逻辑是否立即需要。
② aggressiveLazyLoading（触发方式）
作用：控制延迟加载的触发条件。
默认值：false。
请注意，此配置仅在总开关lazyLoadingEnabled设置为true时生效。
- 若设为true：调用主对象的任何方法（如toString()、equals()或普通getter）都可能意外触发关联数据的加载。
- 若设为false：只有明确调用了关联属性自身的getter方法时，才会触发加载。这是最符合“懒加载”预期的标准行为。
2. 子查询Mapper配置
无论是association还是collection标签，其select属性所指向的子查询方法，都必须在对应的Mapper XML文件中明确定义。
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属性：触发一对一延迟加载，执行第二条SQL查询用户信息
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());
}
通过上述流程可见，按需加载机制被完美实现，有效避免了N+1查询问题。
七、关键注意事项与常见问题
- 忘记开启全局延迟加载
全局开关lazyLoadingEnabled（默认false）控制所有未显式设置fetchType的关联查询。而局部属性fetchType="lazy"可以让单个关联独立实现延迟加载，优先级更高。 - 子查询方法不存在或路径写错
select属性必须填写全限定名（即包含命名空间的方法全路径），因为它调用的是另一个Mapper文件中的方法。 - 实体类属性名不匹配
配置中的property属性必须和实体类中定义的属性名完全一致，区分大小写。 - 标签区分
一对多用collection，一对一用association，两者不可混用。
八、延迟加载的核心优势
- 显著提升性能：避免查询当前业务逻辑不需要的关联数据，大幅降低数据库压力。
- 有效解决N+1问题：在查询主数据时，不会自动触发关联数据的查询，从而从根源上避免了N+1查询问题。
- 灵活适配业务需求：当业务只需要主数据时，不会产生任何冗余的SQL查询，代码更高效。
- 通用性强：配置方案同时完美支持一对多、一对一等多种关联场景。
九、总结与最佳实践
- 单表查询：优先使用
resultType，无需复杂配置，简洁高效。 - 一对一关联查询：必须使用
resultMap + association组合进行配置。 - 一对多关联查询：必须使用
resultMap + collection组合进行配置。 - 延迟加载核心：关键在于
fetchType="lazy"配置，配合全局开关lazyLoadingEnabled，实现真正的按需加载。 - 核心标签对比：
association（用于一对一）和collection（用于一对多），两者语法结构高度相似，主要区别在于标签名和表示集合元素类型的属性（ja vaTypevsofType）。
