mybatis复杂关联查询应优先选择嵌套结果（join）或嵌套查询（n+1），前者适合数据量小、层级浅的场景，通过和配合resultmap映射；后者适用于主数据量大、关联使用率低的情况，支持延迟加载与按需查询；混合使用可兼顾强弱关联，但嵌套层数建议不超过2～3层。
在 MyBatis 中处理复杂关联查询，关键不是“能不能查”，而是“怎么映射得干净、高效、可维护”。嵌套查询（N+1）和嵌套结果（JOIN 一次性查出）是两种主流策略，选错容易引发性能瓶颈或对象属性为空；用对了，能清晰表达业务关系，也便于后续扩展。
嵌套结果映射：用 JOIN 一次查全，靠 resultMap 拆解
适合关联数据量不大、层级不深的场景，比如查一个订单及其用户、收货地址、商品列表。核心是 SQL 写 JOIN，再用
-
一对一用
：比如 Order → User。SQL 中 SELECT 出 user_id, user_name 等字段，在 resultMap 里用 <association property="user" javatype="User"></association>声明，并在内部配置 user.id、user.name 的 column→property 映射 -
一对多用
：比如 Order → List 。SQL 需保证主表字段（如 order_id）与子表字段（如 item_id、item_name）同在一个结果集； <collection property="items" oftype="OrderItem"></collection>内部同样配置字段映射 - 注意列别名防冲突：多表 JOIN 时，相同字段名（如 id）必须用 AS 起别名（order_id、user_id、item_id），否则 resultMap 无法区分该填到哪个对象的哪个属性
嵌套查询映射：主查 + 子查，按需加载，避免冗余
适合主数据量大、关联数据使用率低，或需要分页/条件过滤子集合的场景。例如查 100 个用户，但只对其中 3 个用户展开查看其全部订单——这时用嵌套查询更合理。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
主 SQL 只查主表：如
SELECT * FROM user WHERE status = 1 -
子查询由 association/collection 触发：在 resultMap 中写
<association property="profile" select="selectUserProfile" column="id"></association>，MyBatis 会自动用主查询返回的每个 user.id 去调用selectUserProfile这个语句 -
慎用 N+1 问题：100 个用户触发 100 次 profile 查询——可通过
@SelectProvider或批量 ID 查询优化（如WHERE id IN (#{ids})），或改用延迟加载（fetchType="lazy"）控制时机
混合使用：复杂场景下的实用组合
真实业务中，往往既有强关联（如用户+档案必须一起展示），又有弱关联（如用户最近 5 条动态可异步加载）。这时可混合配置：
- 主 resultMap 中，用
映射必查的一对一信息（如 user → profile） - 同一 resultMap 中，用
的 select属性映射可选的一对多（如 user → recentPosts），并设fetchType="lazy" - 若子集合本身还需关联其他表（如 post → author + tags），可在子查询的 resultMap 中继续嵌套，形成多层映射链，但建议不超过 2～3 层，否则调试和维护成本陡增
避坑要点：映射失效的常见原因
多数“查出来对象为空”“集合 size=0”问题，不是 SQL 错，而是映射没对上：
- resultMap 的 type 必须是完整类路径，且类有无参构造器；字段 private 无影响，但 getter/setter 缺一不可
- collection 的 ofType、association 的 javaType 不能省略，尤其泛型擦除后 MyBatis 无法推断 List 元素类型
- column 属性值是数据库列名（或别名），不是 Java 属性名；而 property 才是 Java 属性名——写反是高频错误
-
主键映射必须用
标签（哪怕非数据库主键），否则 MyBatis 无法正确聚合嵌套结果，会导致重复创建父对象
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
