1. 从单表查询到关联查询的思维跃迁如果你已经能熟练地用 MyBatis 写一些单表的增删改查感觉select * from user where id #{id}这种操作已经手到擒来那么恭喜你你已经跨过了 ORM 框架使用的第一道门槛。但很快你就会遇到一个更真实、也更复杂的场景你的业务逻辑不可能永远只操作一张表。当产品经理拿着原型图过来要求你“在查询订单详情的时候把下单用户的信息、订单里的商品列表以及每个商品的分类都一并展示出来”时你看着数据库里order、user、order_item、product、category这几张表可能会瞬间感到头皮发麻。这就是关联查询的世界。在 MyBatis 的mapper.xml文件中select元素远不止是执行一条 SQL 那么简单它更是你处理对象间复杂关系的核心工具。一对一、一对多、多对多这些听起来像数据库原理课上的术语实际上是你日常开发中绕不开的“硬骨头”。处理得好代码清晰性能高效处理不好就是 N1 查询问题、数据映射混乱、性能瓶颈的源头。今天我们就抛开那些简单的单表示例深入 MyBatis 的select元素看看它如何优雅地解决对象关联映射这个经典难题。我会结合我这些年趟过的坑把每种关联类型的核心配置、底层原理以及那些官方文档里不会写的“骚操作”和注意事项给你掰开揉碎了讲清楚。2. 关联映射的基石resultMap深度解析在深入一对一、一对多之前我们必须先彻底理解 MyBatis 数据映射的基石——resultMap。很多人觉得它就是个简单的字段匹配规则那就大错特错了。它是解耦 SQL 列与 Java 对象属性的关键更是处理复杂嵌套映射的唯一手段。2.1 基础映射与自动映射的陷阱最简单的resultMap是这样的resultMap idBaseResultMap typecom.example.model.User id propertyid columnid/ result propertyusername columnusername/ result propertyemail columnemail/ /resultMapid标签用于指定主键字段这有助于提高性能如缓存识别。result则用于普通字段。但更多时候我们依赖 MyBatis 的“自动映射”功能只要数据库列名或别名与 Java 对象属性名遵循驼峰转换规则如user_name映射到userName我们就可以省略这些显式配置。然而自动映射的坑就在这里。当你的 SQL 使用了复杂的连接JOIN时多张表可能存在同名字段。例如user表和order表都有id和name字段。如果你写SELECT u.*, o.* FROM user u JOIN order o ON u.id o.user_id并且使用自动映射到一个组合的UserOrderDTO对象上MyBatis 会尝试将所有的列都映射进去结果就是后面表的字段值会覆盖前面表的同名字段导致数据错乱。这是关联查询中最容易踩的第一个坑。解决方案在涉及多表关联的查询中永远不要使用SELECT *。必须为每个字段显式指定别名并且最好配合显式的resultMap。例如SELECT u.id as user_id, u.name as user_name, o.id as order_id, o.order_no as order_order_no, o.amount as order_amount FROM user u JOIN order o ON u.id o.user_id这样在resultMap里你就可以清晰地区分开userId和orderId了。2.2resultMap的继承与复用在大型项目中同一个实体对象可能被多个查询使用每个查询返回的字段集可能不同有的查询只返回基础字段有的查询返回包含敏感信息的全部字段。为每个场景都写一个完整的resultMap会导致大量重复代码。这时resultMap的extends属性就派上用场了。你可以定义一个最基础的BaseResultMap只包含主键和最基本字段。其他更复杂的resultMap可以继承它并添加额外的字段或关联映射。resultMap idBaseUserMap typeUser id propertyid columnid/ result propertyusername columnusername/ /resultMap resultMap idUserWithDetailMap extendsBaseUserMap typeUser !-- 继承了 id 和 username 的映射 -- result propertyemail columnemail/ result propertyphone columnphone/ association propertyprofile resultMapProfileMap/ !-- 后续会讲 -- /resultMap这样做的好处是当基础实体的字段发生变化时你只需要修改BaseUserMap即可。这是一种非常重要的 DRYDon‘t Repeat Yourself实践。3. 一对一关联association的两种玩法与性能抉择一对一关联在业务中非常常见比如一个用户User对应一个档案Profile一个订单Order对应一个收货地址Address。在 MyBatis 中一对一映射主要通过association标签实现。它有两种主流的配置方式嵌套结果映射和嵌套查询。这两种方式的选择直接决定了查询的性能和代码的清晰度。3.1 嵌套结果映射单次查询解决战斗这是最高效、也是最推荐的方式。它的原理是通过一条复杂的 SQL JOIN 语句将主表和关联表的数据一次性查询出来然后通过resultMap的嵌套配置将结果集映射到主对象的关联属性中。假设我们有User和Profile实体一个用户有一个档案。resultMap idUserWithProfileResultMap typeUser id propertyid columnuser_id/ result propertyusername columnusername/ result propertyemail columnemail/ !-- 关键association 标签 -- association propertyprofile javaTypeProfile id propertyid columnprofile_id/ !-- 注意column 对应查询结果中的别名 -- result propertyrealName columnreal_name/ result propertyage columnage/ result propertygender columngender/ /association /resultMap select idselectUserWithProfile resultMapUserWithProfileResultMap SELECT u.id as user_id, u.username, u.email, p.id as profile_id, -- 必须使用别名区分同名字段 p.real_name, p.age, p.gender FROM user u LEFT JOIN user_profile p ON u.id p.user_id WHERE u.id #{userId} /select核心要点property指定主实体User中关联属性profile的名字。javaType指定关联属性的完整 Java 类名可省略MyBatis 通常能推断。在association内部像配置普通resultMap一样配置关联对象Profile的字段映射。column属性必须与 SQL 查询语句中定义的列别名严格一致。SQL 语句使用了LEFT JOIN这意味着即使某个用户没有档案Profile 为 NULL查询也会返回用户信息其profile属性为null。如果使用INNER JOIN则只会返回有档案的用户。为什么这是最高效的因为只需要一次数据库往返Round-trip就获取了所有需要的数据。数据库优化器可以对整条 JOIN 语句进行优化。3.2 嵌套查询清晰但危险的“N1”陷阱另一种方式是将关联对象的查询独立出来通过第一次查询得到主对象的主键然后用这个主键去执行第二次查询获取关联对象。这需要在association标签中使用select属性。!-- 首先需要一个根据 userId 查询 Profile 的语句 -- select idselectProfileByUserId resultTypeProfile SELECT * FROM user_profile WHERE user_id #{userId} /select !-- 然后在主查询的 resultMap 中引用它 -- resultMap idUserWithProfileBySelectMap typeUser id propertyid columnid/ result propertyusername columnusername/ result propertyemail columnemail/ !-- 关键association 使用 select 属性 -- association propertyprofile columnid selectselectProfileByUserId/ /resultMap select idselectUserById resultMapUserWithProfileBySelectMap SELECT * FROM user WHERE id #{id} /select核心要点select指定另一个select语句的完整 ID如namespace.id。column指定将当前结果中的哪一列的值作为参数传递给select属性指定的查询语句。这里{id}会作为参数#{userId}传入selectProfileByUserId。这种方式的巨大隐患著名的“N1 查询问题”。假设你有一个查询selectAllUsers返回 100 个用户N100。对于返回的这 100 条用户记录MyBatis 会为每一条记录额外执行一次selectProfileByUserId查询。最终为了获取 100 个用户及其档案你执行了 1主查询 100关联查询 101 次数据库查询这在数据量稍大时就是性能灾难。什么情况下可以用嵌套查询只有在关联数据极少被用到或者你明确知道主查询只会返回单条或极少几条记录时才可以考虑。更多时候应该使用嵌套结果映射。MyBatis 提供了fetchTypelazy属性可以设置为懒加载但需要开启全局懒加载配置且在某些场景下如 Session 关闭后容易引发异常需谨慎使用。4. 一对多关联collection与聚合结果集的映射艺术一对多关联更为普遍比如一个博客Blog有多条评论Comment一个订单Order有多个订单项OrderItem。处理一对多我们使用collection标签。它同样有嵌套结果映射和嵌套查询两种方式而嵌套结果映射的写法是一对多关联的难点和核心。4.1 嵌套结果映射结果集行的“折叠”逻辑一对多的嵌套结果映射其 SQL 通常使用LEFT JOIN。这会导致结果集行数膨胀一个主记录如订单关联 N 条子记录如订单项查询结果就会返回 N 行主记录的数据在每一行中都是重复的。MyBatis 的collection的魔力就在于它能自动识别主对象的主键将这些“多行”数据“折叠”成一个主对象并将其下的多个子对象放入一个集合List中。resultMap idOrderWithItemsResultMap typeOrder id propertyid columnorder_id/ !-- 关键id 标签用于标识主对象唯一性 -- result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 关键collection 标签 -- collection propertyitemList ofTypeOrderItem id propertyid columnitem_id/ !-- 子对象的主键同样重要 -- result propertyproductName columnproduct_name/ result propertyprice columnprice/ result propertyquantity columnquantity/ /collection /resultMap select idselectOrderWithItems resultMapOrderWithItemsResultMap SELECT o.id as order_id, o.order_no, o.amount, oi.id as item_id, oi.product_name, oi.price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id #{orderId} /select假设订单 ID 为 1 的订单有 2 个商品项上面的查询会返回 2 行数据。MyBatis 在映射时的逻辑是根据Order的id标签order_id列识别唯一的主对象。第一行数据创建一个Order对象并创建一个ListOrderItem将第一行的订单项数据创建为一个OrderItem对象放入列表。处理第二行数据时发现order_id仍然是 1它知道这是同一个Order对象。于是它不再创建新的 Order 对象而是找到已创建的Order对象将第二行的订单项数据创建为另一个OrderItem对象追加到同一个itemList集合中。这就是“折叠”的过程。这里有两个至关重要的细节主对象的id标签必须配置正确这是 MyBatis 判断行是否属于同一个主对象的依据。如果没配或配错会导致创建多个重复的主对象。子对象也建议配置id标签这有助于 MyBatis 在内部进行性能优化识别子对象的唯一性。虽然在一对多映射中子对象重复通常不会导致问题但良好的习惯能避免潜在bug。4.2 一对多下的分页“大坑”这是一个极其常见的生产问题。当你需要对一个一对多关联查询的结果进行分页时比如“查询所有订单及其商品项每页10条订单”。如果你直接使用PageHelper等分页插件在LEFT JOIN后写LIMIT 0, 10数据库会先进行连接产生一个膨胀的结果集比如10个订单平均每个有3个商品项结果集是30行然后对这个30行的结果集取前10行。这会导致主记录数据不完整你可能只拿到了4个订单因为前10行只包含了4个订单的部分数据MyBatis 映射后Order列表就只有4个对象完全错了。解决方案有两种内存分页不推荐大数据量先查询所有满足条件的订单ID单表查询效率高再用这些ID列表去关联查询详情。这需要业务层做两次查询和内存中组装。使用子查询或窗口函数推荐先分页查询出主表数据订单再通过主键列表去查询关联数据。这可以用 MyBatis 的嵌套查询collection select...实现并配合Param传递主键列表。虽然可能有多条SQL但避免了结果集膨胀分页准确。!-- 1. 先分页查订单ID -- select idselectOrderIdsByPage resultTypelong SELECT id FROM order WHERE ... LIMIT #{page.offset}, #{page.size} /select !-- 2. 根据ID列表查订单详情及商品项 -- select idselectOrdersWithItemsByIds resultMapOrderWithItemsResultMap SELECT o.*, oi.* FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id IN foreach collectionorderIds itemid open( separator, close) #{id} /foreach ORDER BY o.id !-- 保持顺序便于后续组装 -- /select在 Service 层先调用第一步拿到一页的ID再调用第二步用这些ID获取完整数据。这是处理一对多分页最稳健的方式。5. 多对多关联拆解为两个一对多的组合拳多对多关系在数据库中需要通过一个中间表来实现。例如学生Student和课程Course是多对多关系通过选课表student_course连接。在 MyBatis 映射中我们并不直接处理“多对多”而是将其视角转换。从一个学生的角度看他选择了多门课程这是一对多一个 Student 对应多个 Course。从一门课程的角度看它被多个学生选择这也是一对多一个 Course 对应多个 Student。因此我们只需要在一端的实体中配置一个指向另一端的collection即可。通常根据业务需求来决定在哪一端配置。示例查询学生及其所选课程!-- 课程实体的基础映射 -- resultMap idCourseResultMap typeCourse id propertyid columncourse_id/ result propertyname columncourse_name/ result propertycredit columncredit/ /resultMap !-- 学生实体及其课程集合的映射 -- resultMap idStudentWithCoursesResultMap typeStudent id propertyid columnstudent_id/ result propertyname columnstudent_name/ !-- 通过中间表关联课程 -- collection propertycourseList resultMapCourseResultMap/ /resultMap select idselectStudentWithCourses resultMapStudentWithCoursesResultMap SELECT s.id as student_id, s.name as student_name, c.id as course_id, c.name as course_name, c.credit FROM student s LEFT JOIN student_course sc ON s.id sc.student_id LEFT JOIN course c ON sc.course_id c.id WHERE s.id #{studentId} /select注意SQL 中需要连接两次学生表 - 中间表 - 课程表。映射逻辑和一对多完全一样MyBatis 会根据student_id将多行课程数据“折叠”到一个Student对象的courseList中。如果你想从课程端查询选了该课程的所有学生配置是完全对称的在Course的resultMap里配置一个collection propertystudentList ...即可。多对多查询的要点清晰的三表 JOINSQL 必须清晰地体现出从主表到中间表再到关联表的路径。列别名至关重要三张表很可能有大量同名字段id,name必须为每个需要的字段起一个独一无二的别名。性能考虑多对多关联通常会产生更大的结果集膨胀一个学生选10门课结果就是10行。所有在一对多中提到的问题特别是分页问题在这里会更加严重务必采用“先查主键再查详情”的策略。6. 高级技巧与实战避坑指南掌握了基本配置我们来看看那些能让你的 MyBatis 映射更上一层楼的高级技巧和常见深坑。6.1 使用Param注解传递多个参数给嵌套查询在嵌套查询association select...或collection select...中如果你需要传递多个列的值给子查询column属性可以接受一个复合值。association propertydetail selectcom.example.mapper.DetailMapper.selectByUserAndType column{userIdid, typeuser_type}/这里column”{userIdid, typeuser_type}“表示将当前结果行中的id列值作为参数userIduser_type列值作为参数type传递给selectByUserAndType方法。该方法需要定义对应的参数// DetailMapper.java Detail selectByUserAndType(Param(“userId”) Long userId, Param(“type”) Integer type);6.2 鉴别器discriminator根据条件映射不同的关联类型这是一个非常强大但少用的功能。它允许你根据查询结果中某个字段的值来决定如何映射关联对象。典型的应用场景是“多种类型的消息”或“多种支付方式”。resultMap idMessageResultMap typeBaseMessage id propertyid columnid/ result propertytype columnmsg_type/ discriminator javaTypeint columnmsg_type case value1 resultMapTextMessageMap/ case value2 resultMapImageMessageMap/ case value3 resultMapVideoMessageMap/ /discriminator /resultMap resultMap idTextMessageMap typeTextMessage extendsMessageResultMap result propertycontent columncontent/ /resultMap !-- 其他类型的 resultMap --当msg_type为 1 时MyBatis 会使用TextMessageMap来映射整行数据最终得到一个TextMessage对象。这避免了为每种类型写不同的查询语句。6.3 警惕懒加载的“Session已关闭”异常如果你在association或collection上配置了fetchType“lazy”或开启了全局懒加载关联数据会在第一次被访问时才加载。这在一个请求会话SqlSession内是没问题的。但如果你在 Service 层方法中查询了一个对象然后关闭了 SqlSession接着在 Controller 或视图层如 Thymeleaf 模板中尝试访问其懒加载属性就会抛出LazyInitializationException。解决方案在视图层渲染前完成数据加载确保所有需要的数据在 Service 层或更早的阶段就已经被访问例如在 Service 方法里调用getter方法触发加载。使用“开放 Session 在视图”模式这是一种在 Web 应用中常见的模式通过过滤器或拦截器将 SqlSession 的生命周期延长到整个 HTTP 请求结束。但这需要框架支持如 Spring 集成 MyBatis 时可以使用Transactional或在配置中设置且需注意事务边界。对于简单场景直接使用嵌套结果映射Eager Loading更省心。6.4 关于fetchSize与大数据量查询在提供的网络热词中出现了mybatis fetchsize“1000”。fetchSize是 JDBC 驱动的一个性能调优参数它指示数据库每次从网络连接中获取多少行数据到客户端内存中。默认值通常较小如 10 或 50。当你需要处理非常大的结果集比如数据导出时设置一个合理的fetchSize如 1000可以显著减少客户端与数据库服务器的网络交互次数从而提高性能。你可以在select标签中直接设置select id“selectLargeData” resultMap“xxx” fetchSize“1000” SELECT * FROM large_table /select注意fetchSize并非越大越好。设置过大会消耗大量客户端内存。它最适合在流式处理结果集使用ResultHandler接口的场景下进行调优。对于普通的将全部结果加载到List中的查询过大的fetchSize可能反而会导致内存溢出。6.5#{}与${}在动态 SQL 中的正确选择这虽然不直接关联映射但在构建关联查询的 SQL 时至关重要。#{id}是预编译参数安全能防止 SQL 注入。${orderBy}是字符串替换直接将值拼接到 SQL 语句中。在ORDER BY、GROUP BY或动态表名列名中必须使用${}因为#{}会在值两边加上引号导致ORDER BY ‘id’这样的错误语法。select id“dynamicSelect” resultMap“...” SELECT * FROM user if test“orderBy ! null” ORDER BY ${orderBy} !-- 正确 -- !-- ORDER BY #{orderBy} 错误会导致 ORDER BY id -- /if /select但是对于${}的内容你必须确保其安全性绝对不能接受来自用户未经处理的直接输入否则就是 SQL 注入漏洞。通常这类参数应该在服务端用一个枚举或白名单来校验。从简单的单表查询到处理一对一、一对多、多对多这些复杂的对象关系select元素的resultMap映射能力是 MyBatis 的灵魂所在。理解并熟练运用嵌套结果映射是写出高性能、易维护的 MyBatis 代码的关键。而警惕嵌套查询的 N1 问题、处理好一对多分页的陷阱则是从“会用”到“用好”的必经之路。最后记住一个核心原则尽量通过单条精心设计的 JOIN SQL 和嵌套resultMap来完成数据组装这是关系型数据库和 MyBatis 结合的最佳实践。当你面对下一个复杂的页面数据展示需求时不妨先静下心来设计好实体关系与resultMap你会发现很多问题都迎刃而解了。 1. 从单表查询到关联查询的思维跃迁如果你已经能熟练地用 MyBatis 写一些单表的增删改查感觉select * from user where id #{id}这种操作已经手到擒来那么恭喜你你已经跨过了 ORM 框架使用的第一道门槛。但很快你就会遇到一个更真实、也更复杂的场景你的业务逻辑不可能永远只操作一张表。当产品经理拿着原型图过来要求你“在查询订单详情的时候把下单用户的信息、订单里的商品列表以及每个商品的分类都一并展示出来”时你看着数据库里order、user、order_item、product、category这几张表可能会瞬间感到头皮发麻。这就是关联查询的世界。在 MyBatis 的mapper.xml文件中select元素远不止是执行一条 SQL 那么简单它更是你处理对象间复杂关系的核心工具。一对一、一对多、多对多这些听起来像数据库原理课上的术语实际上是你日常开发中绕不开的“硬骨头”。处理得好代码清晰性能高效处理不好就是 N1 查询问题、数据映射混乱、性能瓶颈的源头。今天我们就抛开那些简单的单表示例深入 MyBatis 的select元素看看它如何优雅地解决对象关联映射这个经典难题。我会结合我这些年趟过的坑把每种关联类型的核心配置、底层原理以及那些官方文档里不会写的“骚操作”和注意事项给你掰开揉碎了讲清楚。2. 关联映射的基石resultMap深度解析在深入一对一、一对多之前我们必须先彻底理解 MyBatis 数据映射的基石——resultMap。很多人觉得它就是个简单的字段匹配规则那就大错特错了。它是解耦 SQL 列与 Java 对象属性的关键更是处理复杂嵌套映射的唯一手段。2.1 基础映射与自动映射的陷阱最简单的resultMap是这样的resultMap idBaseResultMap typecom.example.model.User id propertyid columnid/ result propertyusername columnusername/ result propertyemail columnemail/ /resultMapid标签用于指定主键字段这有助于提高性能如缓存识别。result则用于普通字段。但更多时候我们依赖 MyBatis 的“自动映射”功能只要数据库列名或别名与 Java 对象属性名遵循驼峰转换规则如user_name映射到userName我们就可以省略这些显式配置。然而自动映射的坑就在这里。当你的 SQL 使用了复杂的连接JOIN时多张表可能存在同名字段。例如user表和order表都有id和name字段。如果你写SELECT u.*, o.* FROM user u JOIN order o ON u.id o.user_id并且使用自动映射到一个组合的UserOrderDTO对象上MyBatis 会尝试将所有的列都映射进去结果就是后面表的字段值会覆盖前面表的同名字段导致数据错乱。这是关联查询中最容易踩的第一个坑。解决方案在涉及多表关联的查询中永远不要使用SELECT *。必须为每个字段显式指定别名并且最好配合显式的resultMap。例如SELECT u.id as user_id, u.name as user_name, o.id as order_id, o.order_no as order_order_no, o.amount as order_amount FROM user u JOIN order o ON u.id o.user_id这样在resultMap里你就可以清晰地区分开userId和orderId了。2.2resultMap的继承与复用在大型项目中同一个实体对象可能被多个查询使用每个查询返回的字段集可能不同有的查询只返回基础字段有的查询返回包含敏感信息的全部字段。为每个场景都写一个完整的resultMap会导致大量重复代码。这时resultMap的extends属性就派上用场了。你可以定义一个最基础的BaseResultMap只包含主键和最基本字段。其他更复杂的resultMap可以继承它并添加额外的字段或关联映射。resultMap idBaseUserMap typeUser id propertyid columnid/ result propertyusername columnusername/ /resultMap resultMap idUserWithDetailMap extendsBaseUserMap typeUser !-- 继承了 id 和 username 的映射 -- result propertyemail columnemail/ result propertyphone columnphone/ association propertyprofile resultMapProfileMap/ !-- 后续会讲 -- /resultMap这样做的好处是当基础实体的字段发生变化时你只需要修改BaseUserMap即可。这是一种非常重要的 DRYDon‘t Repeat Yourself实践。3. 一对一关联association的两种玩法与性能抉择一对一关联在业务中非常常见比如一个用户User对应一个档案Profile一个订单Order对应一个收货地址Address。在 MyBatis 中一对一映射主要通过association标签实现。它有两种主流的配置方式嵌套结果映射和嵌套查询。这两种方式的选择直接决定了查询的性能和代码的清晰度。3.1 嵌套结果映射单次查询解决战斗这是最高效、也是最推荐的方式。它的原理是通过一条复杂的 SQL JOIN 语句将主表和关联表的数据一次性查询出来然后通过resultMap的嵌套配置将结果集映射到主对象的关联属性中。假设我们有User和Profile实体一个用户有一个档案。resultMap idUserWithProfileResultMap typeUser id propertyid columnuser_id/ result propertyusername columnusername/ result propertyemail columnemail/ !-- 关键association 标签 -- association propertyprofile javaTypeProfile id propertyid columnprofile_id/ !-- 注意column 对应查询结果中的别名 -- result propertyrealName columnreal_name/ result propertyage columnage/ result propertygender columngender/ /association /resultMap select idselectUserWithProfile resultMapUserWithProfileResultMap SELECT u.id as user_id, u.username, u.email, p.id as profile_id, -- 必须使用别名区分同名字段 p.real_name, p.age, p.gender FROM user u LEFT JOIN user_profile p ON u.id p.user_id WHERE u.id #{userId} /select核心要点property指定主实体User中关联属性profile的名字。javaType指定关联属性的完整 Java 类名可省略MyBatis 通常能推断。在association内部像配置普通resultMap一样配置关联对象Profile的字段映射。column属性必须与 SQL 查询语句中定义的列别名严格一致。SQL 语句使用了LEFT JOIN这意味着即使某个用户没有档案Profile 为 NULL查询也会返回用户信息其profile属性为null。如果使用INNER JOIN则只会返回有档案的用户。为什么这是最高效的因为只需要一次数据库往返Round-trip就获取了所有需要的数据。数据库优化器可以对整条 JOIN 语句进行优化。3.2 嵌套查询清晰但危险的“N1”陷阱另一种方式是将关联对象的查询独立出来通过第一次查询得到主对象的主键然后用这个主键去执行第二次查询获取关联对象。这需要在association标签中使用select属性。!-- 首先需要一个根据 userId 查询 Profile 的语句 -- select idselectProfileByUserId resultTypeProfile SELECT * FROM user_profile WHERE user_id #{userId} /select !-- 然后在主查询的 resultMap 中引用它 -- resultMap idUserWithProfileBySelectMap typeUser id propertyid columnid/ result propertyusername columnusername/ result propertyemail columnemail/ !-- 关键association 使用 select 属性 -- association propertyprofile columnid selectselectProfileByUserId/ /resultMap select idselectUserById resultMapUserWithProfileBySelectMap SELECT * FROM user WHERE id #{id} /select核心要点select指定另一个select语句的完整 ID如namespace.id。column指定将当前结果中的哪一列的值作为参数传递给select属性指定的查询语句。这里{id}会作为参数#{userId}传入selectProfileByUserId。这种方式的巨大隐患著名的“N1 查询问题”。假设你有一个查询selectAllUsers返回 100 个用户N100。对于返回的这 100 条用户记录MyBatis 会为每一条记录额外执行一次selectProfileByUserId查询。最终为了获取 100 个用户及其档案你执行了 1主查询 100关联查询 101 次数据库查询这在数据量稍大时就是性能灾难。什么情况下可以用嵌套查询只有在关联数据极少被用到或者你明确知道主查询只会返回单条或极少几条记录时才可以考虑。更多时候应该使用嵌套结果映射。MyBatis 提供了fetchTypelazy属性可以设置为懒加载但需要开启全局懒加载配置且在某些场景下如 Session 关闭后容易引发异常需谨慎使用。4. 一对多关联collection与聚合结果集的映射艺术一对多关联更为普遍比如一个博客Blog有多条评论Comment一个订单Order有多个订单项OrderItem。处理一对多我们使用collection标签。它同样有嵌套结果映射和嵌套查询两种方式而嵌套结果映射的写法是一对多关联的难点和核心。4.1 嵌套结果映射结果集行的“折叠”逻辑一对多的嵌套结果映射其 SQL 通常使用LEFT JOIN。这会导致结果集行数膨胀一个主记录如订单关联 N 条子记录如订单项查询结果就会返回 N 行主记录的数据在每一行中都是重复的。MyBatis 的collection的魔力就在于它能自动识别主对象的主键将这些“多行”数据“折叠”成一个主对象并将其下的多个子对象放入一个集合List中。resultMap idOrderWithItemsResultMap typeOrder id propertyid columnorder_id/ !-- 关键id 标签用于标识主对象唯一性 -- result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 关键collection 标签 -- collection propertyitemList ofTypeOrderItem id propertyid columnitem_id/ !-- 子对象的主键同样重要 -- result propertyproductName columnproduct_name/ result propertyprice columnprice/ result propertyquantity columnquantity/ /collection /resultMap select idselectOrderWithItems resultMapOrderWithItemsResultMap SELECT o.id as order_id, o.order_no, o.amount, oi.id as item_id, oi.product_name, oi.price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id #{orderId} /select假设订单 ID 为 1 的订单有 2 个商品项上面的查询会返回 2 行数据。MyBatis 在映射时的逻辑是根据Order的id标签order_id列识别唯一的主对象。第一行数据创建一个Order对象并创建一个ListOrderItem将第一行的订单项数据创建为一个OrderItem对象放入列表。处理第二行数据时发现order_id仍然是 1它知道这是同一个Order对象。于是它不再创建新的 Order 对象而是找到已创建的Order对象将第二行的订单项数据创建为另一个OrderItem对象追加到同一个itemList集合中。这就是“折叠”的过程。这里有两个至关重要的细节主对象的id标签必须配置正确这是 MyBatis 判断行是否属于同一个主对象的依据。如果没配或配错会导致创建多个重复的主对象。子对象也建议配置id标签这有助于 MyBatis 在内部进行性能优化识别子对象的唯一性。虽然在一对多映射中子对象重复通常不会导致问题但良好的习惯能避免潜在bug。4.2 一对多下的分页“大坑”这是一个极其常见的生产问题。当你需要对一个一对多关联查询的结果进行分页时比如“查询所有订单及其商品项每页10条订单”。如果你直接使用PageHelper等分页插件在LEFT JOIN后写LIMIT 0, 10数据库会先进行连接产生一个膨胀的结果集比如10个订单平均每个有3个商品项结果集是30行然后对这个30行的结果集取前10行。这会导致主记录数据不完整你可能只拿到了4个订单因为前10行只包含了4个订单的部分数据MyBatis 映射后Order列表就只有4个对象完全错了。解决方案有两种内存分页不推荐大数据量先查询所有满足条件的订单ID单表查询效率高再用这些ID列表去关联查询详情。这需要业务层做两次查询和内存中组装。使用子查询或窗口函数推荐先分页查询出主表数据订单再通过主键列表去查询关联数据。这可以用 MyBatis 的嵌套查询collection select...实现并配合Param传递主键列表。虽然可能有多条SQL但避免了结果集膨胀分页准确。!-- 1. 先分页查订单ID -- select idselectOrderIdsByPage resultTypelong SELECT id FROM order WHERE ... LIMIT #{page.offset}, #{page.size} /select !-- 2. 根据ID列表查订单详情及商品项 -- select idselectOrdersWithItemsByIds resultMapOrderWithItemsResultMap SELECT o.*, oi.* FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id IN foreach collectionorderIds itemid open( separator, close) #{id} /foreach ORDER BY o.id !-- 保持顺序便于后续组装 -- /select在 Service 层先调用第一步拿到一页的ID再调用第二步用这些ID获取完整数据。这是处理一对多分页最稳健的方式。5. 多对多关联拆解为两个一对多的组合拳多对多关系在数据库中需要通过一个中间表来实现。例如学生Student和课程Course是多对多关系通过选课表student_course连接。在 MyBatis 映射中我们并不直接处理“多对多”而是将其视角转换。从一个学生的角度看他选择了多门课程这是一对多一个 Student 对应多个 Course。从一门课程的角度看它被多个学生选择这也是一对多一个 Course 对应多个 Student。因此我们只需要在一端的实体中配置一个指向另一端的collection即可。通常根据业务需求来决定在哪一端配置。示例查询学生及其所选课程!-- 课程实体的基础映射 -- resultMap idCourseResultMap typeCourse id propertyid columncourse_id/ result propertyname columncourse_name/ result propertycredit columncredit/ /resultMap !-- 学生实体及其课程集合的映射 -- resultMap idStudentWithCoursesResultMap typeStudent id propertyid columnstudent_id/ result propertyname columnstudent_name/ !-- 通过中间表关联课程 -- collection propertycourseList resultMapCourseResultMap/ /resultMap select idselectStudentWithCourses resultMapStudentWithCoursesResultMap SELECT s.id as student_id, s.name as student_name, c.id as course_id, c.name as course_name, c.credit FROM student s LEFT JOIN student_course sc ON s.id sc.student_id LEFT JOIN course c ON sc.course_id c.id WHERE s.id #{studentId} /select注意SQL 中需要连接两次学生表 - 中间表 - 课程表。映射逻辑和一对多完全一样MyBatis 会根据student_id将多行课程数据“折叠”到一个Student对象的courseList中。如果你想从课程端查询选了该课程的所有学生配置是完全对称的在Course的resultMap里配置一个collection propertystudentList ...即可。多对多查询的要点清晰的三表 JOINSQL 必须清晰地体现出从主表到中间表再到关联表的路径。列别名至关重要三张表很可能有大量同名字段id,name必须为每个需要的字段起一个独一无二的别名。性能考虑多对多关联通常会产生更大的结果集膨胀一个学生选10门课结果就是10行。所有在一对多中提到的问题特别是分页问题在这里会更加严重务必采用“先查主键再查详情”的策略。6. 高级技巧与实战避坑指南掌握了基本配置我们来看看那些能让你的 MyBatis 映射更上一层楼的高级技巧和常见深坑。6.1 使用Param注解传递多个参数给嵌套查询在嵌套查询association select...或collection select...中如果你需要传递多个列的值给子查询column属性可以接受一个复合值。association propertydetail selectcom.example.mapper.DetailMapper.selectByUserAndType column{userIdid, typeuser_type}/这里column”{userIdid, typeuser_type}“表示将当前结果行中的id列值作为参数userIduser_type列值作为参数type传递给selectByUserAndType方法。该方法需要定义对应的参数// DetailMapper.java Detail selectByUserAndType(Param(“userId”) Long userId, Param(“type”) Integer type);6.2 鉴别器discriminator根据条件映射不同的关联类型这是一个非常强大但少用的功能。它允许你根据查询结果中某个字段的值来决定如何映射关联对象。典型的应用场景是“多种类型的消息”或“多种支付方式”。resultMap idMessageResultMap typeBaseMessage id propertyid columnid/ result propertytype columnmsg_type/ discriminator javaTypeint columnmsg_type case value1 resultMapTextMessageMap/ case value2 resultMapImageMessageMap/ case value3 resultMapVideoMessageMap/ /discriminator /resultMap resultMap idTextMessageMap typeTextMessage extendsMessageResultMap result propertycontent columncontent/ /resultMap !-- 其他类型的 resultMap --当msg_type为 1 时MyBatis 会使用TextMessageMap来映射整行数据最终得到一个TextMessage对象。这避免了为每种类型写不同的查询语句。6.3 警惕懒加载的“Session已关闭”异常如果你在association或collection上配置了fetchType“lazy”或开启了全局懒加载关联数据会在第一次被访问时才加载。这在一个请求会话SqlSession内是没问题的。但如果你在 Service 层方法中查询了一个对象然后关闭了 SqlSession接着在 Controller 或视图层如 Thymeleaf 模板中尝试访问其懒加载属性就会抛出LazyInitializationException。解决方案在视图层渲染前完成数据加载确保所有需要的数据在 Service 层或更早的阶段就已经被访问例如在 Service 方法里调用getter方法触发加载。使用“开放 Session 在视图”模式这是一种在 Web 应用中常见的模式通过过滤器或拦截器将 SqlSession 的生命周期延长到整个 HTTP 请求结束。但这需要框架支持如 Spring 集成 MyBatis 时可以使用Transactional或在配置中设置且需注意事务边界。对于简单场景直接使用嵌套结果映射Eager Loading更省心。6.4 关于fetchSize与大数据量查询在提供的网络热词中出现了mybatis fetchsize“1000”。fetchSize是 JDBC 驱动的一个性能调优参数它指示数据库每次从网络连接中获取多少行数据到客户端内存中。默认值通常较小如 10 或 50。当你需要处理非常大的结果集比如数据导出时设置一个合理的fetchSize如 1000可以显著减少客户端与数据库服务器的网络交互次数从而提高性能。你可以在select标签中直接设置select id“selectLargeData” resultMap“xxx” fetchSize“1000” SELECT * FROM large_table /select注意fetchSize并非越大越好。设置过大会消耗大量客户端内存。它最适合在流式处理结果集使用ResultHandler接口的场景下进行调优。对于普通的将全部结果加载到List中的查询过大的fetchSize可能反而会导致内存溢出。6.5#{}与${}在动态 SQL 中的正确选择这虽然不直接关联映射但在构建关联查询的 SQL 时至关重要。#{id}是预编译参数安全能防止 SQL 注入。${orderBy}是字符串替换直接将值拼接到 SQL 语句中。在ORDER BY、GROUP BY或动态表名列名中必须使用${}因为#{}会在值两边加上引号导致ORDER BY ‘id’这样的错误语法。select id“dynamicSelect” resultMap“...” SELECT * FROM user if test“orderBy ! null” ORDER BY ${orderBy} !-- 正确 -- !-- ORDER BY #{orderBy} 错误会导致 ORDER BY id -- /if /select但是对于${}的内容你必须确保其安全性绝对不能接受来自用户未经处理的直接输入否则就是 SQL 注入漏洞。通常这类参数应该在服务端用一个枚举或白名单来校验。从简单的单表查询到处理一对一、一对多、多对多这些复杂的对象关系select元素的resultMap映射能力是 MyBatis 的灵魂所在。理解并熟练运用嵌套结果映射是写出高性能、易维护的 MyBatis 代码的关键。而警惕嵌套查询的 N1 问题、处理好一对多分页的陷阱则是从“会用”到“用好”的必经之路。最后记住一个核心原则尽量通过单条精心设计的 JOIN SQL 和嵌套resultMap来完成数据组装这是关系型数据库和 MyBatis 结合的最佳实践。当你面对下一个复杂的页面数据展示需求时不妨先静下心来设计好实体关系与resultMap你会发现很多问题都迎刃而解了。 
![洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表](http://pic.xiahunao.cn/yaotu/洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表)
