在MyBatis中处理一对多和多对多关联时，通常面临两种实现方式的选择：直接使用SQL连接查询生成扁平化结果集 ，或通过<collection>/<association>标签的嵌套映射。
一、一对多关联的两种实现方式对比
1. SQL连接查询
-
实现原理 ：
通过单次SQL查询（如LEFT JOIN）一次性获取用户及其所有设备数据，结果集为扁平化结构（每行包含用户字段+设备字段）。使用ResultMap手动映射到自定义VO（Value Object）的List中。xml<!-- 示例：查询用户及设备列表 --> <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属性指向另一查询。xml<!-- 示例：嵌套查询方式 --> <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属性自引用 同一查询方法，形成递归映射。xml<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}"传递多参数 ：xml<collection property="items" ofType="Item" select="selectItems" column="{userId=id, date=createTime}"/> -
优势 ：
- 解耦复杂查询逻辑，提升 SQL 可复用性；
- 灵活支持多参数传递，避免连接查询的字段耦合。
3. 为何第二种方式使用较少？
- 性能优先：N+1问题在大数据量场景下极易引发性能灾难，而连接查询可通过批量处理规避。
- 开发效率优先：多数业务场景更倾向编写单SQL快速实现，而非拆分多个映射。
二、多对多关联为何使用更少？
MyBatis官方文档明确建议避免直接映射多对多 ，而是通过中间表拆解为两个一对多关系。以用户（user）和角色（role）为例：
sql
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. 实现方式
-
查询时通过中间表连接 ：
xml<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.两种方案的核心对比
| 特性 | SQL 连接查询（嵌套结果） | collection 标签（嵌套查询） |
|---|---|---|
| 查询次数 | 1 次 SQL（JOIN 多表查询） | N+1 次 SQL（主查询 + N 次子查询） |
| 性能 | 高效（大数据量优先） | 低效（N+1 问题严重） |
| SQL 复杂度 | 高（需处理字段别名、重复数据） | 低（单表简单查询） |
| 代码复用性 | 差（需为每个 JOIN 写定制 SQL） | 高（子查询可复用） |
| 适用场景 | 数据量大、实时性要求高 | 数据量小、层级结构（如树形菜单） |
| 字段冲突处理 | 支持 | 无需处理（单表查询无冲突） |
| 懒加载支持 | 不支持 | 支持（fetchType="lazy"） |