MyBatis ：何时选择连接查询，何时使用＜collection＞标签？

在MyBatis中处理一对多和多对多关联时，通常面临两种实现方式的选择：直接使用SQL连接查询生成扁平化结果集，或通过<collection>/<association>标签的嵌套映射。

一、一对多关联的两种实现方式对比

1. SQL连接查询

• 实现原理：
  通过单次SQL查询（如LEFT JOIN）一次性获取用户及其所有设备数据，结果集为扁平化结构（每行包含用户字段+设备字段）。使用ResultMap手动映射到自定义VO（Value Object）的List中。

  <!-- 示例：查询用户及设备列表 -->
  <select id="getUserWithDevices" resultMap="userDeviceMap">
      SELECT u.*, d.device_id, d.device_name
      FROM user u
      LEFT JOIN user_device d ON u.user_id = d.user_id
  </select>
  
  <resultMap id="userDeviceMap" type="UserDeviceVO">
      <id property="userId" column="user_id"/>
      <!-- 用户字段映射 -->
      <collection property="devices" ofType="Device">
          <id property="deviceId" column="device_id"/>
          <result property="deviceName" column="device_name"/>
      </collection>
  </resultMap>
  

• 优点：
  • 一次查询完成：减少数据库交互次数，避免N+1问题。
  • 直观易控：SQL可读性强，调试优化方便（如分页可直接用LIMIT）。
• 缺点：
  • 结果集冗余：用户字段在每行重复，数据量大时可能影响传输效率。
  • 分页问题：直接对连接结果分页可能导致主表数据丢失（需改用子查询）。

2. <collection>标签的嵌套查询

2.1.示例

• 实现原理：
  在主查询获取用户列表后，通过额外SQL按需加载每个用户的设备集合。需在<resultMap>中定义<collection>并指定select属性指向另一查询。

  <!-- 示例：嵌套查询方式 -->
  <select id="getUser" resultMap="userResult">
      SELECT * FROM user
  </select>
  
  <resultMap id="userResult" type="User">
      <collection property="devices" ofType="Device" 
                 select="getDevicesByUserId" column="user_id"/>
  </resultMap>
  
  <select id="getDevicesByUserId" resultType="Device">
      SELECT * FROM user_device WHERE user_id = #{userId}
  </select>
  

• 优点：
  • 按需加载：支持延迟加载（lazy loading），减少不必要的数据传输。
  • 逻辑解耦：设备查询独立，复用性强。
• 缺点：
  • N+1查询问题：若主查询返回N个用户，设备查询会执行N次，性能瓶颈显著。
  • 配置复杂：需维护多个SQL语句和映射关系，可读性降低。

2.2.适用 collection 标签的核心场景

2.2.1. 树形/递归结构的数据加载

• 场景说明：处理无限层级的数据（如组织架构、分类树、权限菜单），需递归查询子节点。
• 技术实现：
  在 collection 标签中通过 select 属性自引用同一查询方法，形成递归映射。

  <resultMap id="CategoryMap" type="Category">
      <id property="id" column="id"/>
      <collection property="children" ofType="Category" 
                 select="selectCategoriesByParentId" column="id"/>
  </resultMap>
  

• 优势：
  • 自动构建层级关系，代码简洁；
  • 避免连接查询的冗余字段和复杂别名。
• 风险提示：
  数据量大时递归查询可能引发深度 N+1 问题（需结合懒加载或批量加载优化）。

2.2.2. 需要延迟加载（Lazy Loading）关联数据

• 场景说明：主表数据量大，但关联数据（如用户设备列表）仅在部分业务逻辑中用到，需按需加载。
• 技术实现：
  在 collection 中配置 fetchType="lazy"，首次查询仅加载主对象，访问关联属性时再触发子查询。
• 优势：
  • 减少无效数据传输，提升首屏响应速度；
  • 避免连接查询中因重复字段导致的内存浪费。
• 限制：
  需开启全局懒加载配置（aggressiveLazyLoading=false），否则可能意外触发查询。

2.2.3. 子查询需复用或参数复杂

• 场景说明：
  • 子查询逻辑独立且被多处调用（如根据用户 ID+时间范围查询设备）；
  • 子查询需传递多个参数（如用户 ID 和创建时间）。
• 技术实现：
  通过 column="{param1=col1, param2=col2}" 传递多参数：

  <collection property="items" ofType="Item" 
             select="selectItems" 
             column="{userId=id, date=createTime}"/>
  

• 优势：
  • 解耦复杂查询逻辑，提升 SQL 可复用性；
  • 灵活支持多参数传递，避免连接查询的字段耦合。

3. 为何第二种方式使用较少？

• 性能优先：N+1问题在大数据量场景下极易引发性能灾难，而连接查询可通过批量处理规避。
• 开发效率优先：多数业务场景更倾向编写单SQL快速实现，而非拆分多个映射。

二、多对多关联为何使用更少？

MyBatis官方文档明确建议避免直接映射多对多，而是通过中间表拆解为两个一对多关系。以用户（user）和角色（role）为例：

CREATE TABLE user_role (  -- 中间表
    user_id INT,
    role_id INT,
    FOREIGN KEY (user_id) REFERENCES user(id),
    FOREIGN KEY (role_id) REFERENCES role(id)
);

1. 实现方式

• 查询时通过中间表连接：

  <select id="getUserWithRoles" resultMap="userRoleMap">
      SELECT u.*, r.*
      FROM user u
      JOIN user_role ur ON u.id = ur.user_id
      JOIN role r ON ur.role_id = r.id
  </select>
  

• 结果映射到VO（含用户基础字段 + 角色列表）。

2. 使用少的原因

• 复杂度高：多对多关系需处理中间表，SQL和映射逻辑更复杂。
• 性能风险：若使用嵌套查询（如<collection>中嵌套另一<collection>），可能引发深度N+1问题（查询用户→查询角色→查询权限链）。
• 业务需求弱化：实际开发中，多对多关联常简化为单向查询（如“查询用户所属角色”，而非“查询角色下所有用户”）。

三、性能问题的深度分析：N+1问题

1. 成因与影响

• 嵌套查询触发机制：主查询每返回一行，即触发一次关联子查询。
• 典型案例：若主查询返回100个用户，设备查询会执行100次，总计101次查询。
• 后果：数据库连接池耗尽、响应时间指数级增长。

2. 解决方案

• 批量加载（Batch Fetch）：
  在MyBatis配置中启用aggressiveLazyLoading或lazyLoadTriggerMethods，合并延迟加载请求。
• 嵌套结果替代嵌套查询：
  改用单SQL连接查询，彻底规避N+1。

总结

• 一对多关联：连接查询是主流选择，因其性能可控、实现直观；嵌套查询仅在深度延迟加载场景有价值。
• 多对多关联：MyBatis不推荐直接实现，应通过中间表拆解为两个一对多，避免复杂度和性能陷阱。

1.两种方案的核心对比