尧图网页设计 
1. 从“查不到”到“查太多”MyBatis关联映射的实战困境如果你用过MyBatis大概率遇到过这两种让人头疼的情况第一种你明明在数据库里看到订单下面有好几条明细但用MyBatis查出来的Order对象它的orderItemList属性却是个空的List你对着日志里打印的SQL看了半天数据都对但就是映射不上。第二种情况更常见你只是想查一个用户的基本信息结果MyBatis给你返回了一个嵌套了好几层的“巨无霸”对象里面包含了用户的所有订单订单里又包含了所有商品详情商品详情里还包含了供应商信息……一次简单的查询背后可能执行了N1条SQL性能瞬间跌入谷底。这两种极端恰恰是MyBatis处理数据关联时最核心的两个概念没搞透的典型表现一对多collection和多对一association。很多人把它们当成简单的配置标签照着网上的例子抄一遍能跑通就以为掌握了。但一到生产环境面对复杂的业务模型和性能要求各种诡异的问题就冒出来了数据映射不全、循环依赖、懒加载失效甚至是开头提到的“开启事务后一级缓存导致查询不到最新数据”这种深坑。今天我们不聊那些干巴巴的概念定义。我想从一个资深开发踩过坑的角度带你重新理解collection和association。我会通过一个贯穿始终的电商案例用户-订单-订单项-商品手把手拆解如何从零构建清晰的关联映射并重点分享那些官方文档里不会写但在真实项目中绕不开的性能陷阱、设计取舍和排查技巧。比如为什么有时候你宁愿写多条单独的查询也不要用一个复杂的联查fetchType”lazy”真的能“懒”起来吗面对“MyBatis查询Mapkey为主键value为对象”这种特定需求关联映射又该如何配合理解了这些你不仅能写出正确的映射更能写出高效、可维护的映射。2. 关联映射的核心不是“联表”而是“对象组装”在深入标签之前我们必须扭转一个常见的误解MyBatis的关联映射其首要目的不是为了写出一个多表连接的复杂SQL而是为了在Java对象层面构建出符合业务语义的领域模型。2.1 场景定义一个经典的电商模型假设我们有四张表user用户表有id,username等字段。order订单表有id,order_no,user_id外键,amount等字段。order_item订单项表有id,order_id外键,product_id外键,quantity,price等字段。product商品表有id,product_name,stock等字段。对应的Java实体类使用Lombok简化// 用户 Data public class User { private Long id; private String username; // 一个用户有多个订单 private ListOrder orderList; } // 订单 Data public class Order { private Long id; private String orderNo; private BigDecimal amount; // 多对一一个订单属于一个用户 private User user; // 一对多一个订单有多个订单项 private ListOrderItem itemList; } // 订单项 Data public class OrderItem { private Long id; private Integer quantity; private BigDecimal price; // 多对一一个订单项属于一个订单 private Order order; // 多对一一个订单项对应一个商品 private Product product; } // 商品 Data public class Product { private Long id; private String productName; private Integer stock; }我们的目标是通过MyBatis在查询Order时能方便地获取到对应的User信息和OrderItem列表并且在OrderItem中能获取到Product详情。这就是典型的“多对一”和“一对多”嵌套。2.2association多对一把外键变成对象属性association用于映射“有一个”的关系即当前对象包含另一个对象的引用。在订单对象中user属性就是一个典型的“多对一”关联。最常见的错误做法在OrderMapper.xml里直接写一个四表连接的超级SQL然后指望MyBatis自动把结果集塞进嵌套的对象里。这会导致SQL极其复杂且难以复用。推荐的做法分步查询与嵌套结果映射。MyBatis提供了两种主要方式。方式一嵌套结果映射单SQL联表查询这种方式适合关联关系简单、数据量不大的场景。!-- OrderMapper.xml -- resultMap idOrderDetailMap typeOrder id propertyid columnorder_id/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 多对一映射关联用户 -- association propertyuser javaTypeUser id propertyid columnuser_id/ result propertyusername columnusername/ !-- 注意如果user还有orderList这里不要映射否则会造成循环 -- /association !-- 一对多映射关联订单项集合稍后详细讲 -- collection propertyitemList ofTypeOrderItem resultMaporderItemMap/ /resultMap !-- 专门定义OrderItem的映射避免重复 -- resultMap idorderItemMap typeOrderItem id propertyid columnitem_id/ result propertyquantity columnquantity/ result propertyprice columnprice/ !-- 订单项关联商品又是一个多对一 -- association propertyproduct javaTypeProduct id propertyid columnproduct_id/ result propertyproductName columnproduct_name/ /association /resultMap select idselectOrderWithDetails resultMapOrderDetailMap SELECT o.id as order_id, o.order_no, o.amount, u.id as user_id, u.username, oi.id as item_id, oi.quantity, oi.price, p.id as product_id, p.product_name FROM order o LEFT JOIN user u ON o.user_id u.id LEFT JOIN order_item oi ON o.id oi.order_id LEFT JOIN product p ON oi.product_id p.id WHERE o.id #{orderId} /select关键点与坑列别名是生命线联表查询必然有重复列名如多个id。必须为每个列起唯一的别名as order_id,as user_id并在resultMap中通过column属性精确指定否则数据会错乱映射。循环引用警告在上面的association property”user”里我们只映射了User的id和username故意没有映射User的orderList属性。如果映射了当MyBatis组装Order对象其user属性指向一个User对象而这个User对象的orderList又包含当前Order对象就会形成死循环导致序列化比如转JSON时栈溢出。这是设计领域模型和结果映射时必须警惕的。性能考量这条SQL通过三次LEFT JOIN一次性取出所有数据。如果订单有10个订单项结果集就会返回10行订单和用户的信息会重复10次。对于数据量大的情况网络传输和内存解析会有压力。方式二嵌套查询分步查询N1问题之源这种方式更符合“单一职责”每个Mapper只关心自己的数据。!-- OrderMapper.xml -- resultMap idOrderDetailMapBySelect typeOrder id propertyid columnid/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 通过select属性指定另一个Mapper的查询方法column指定传递的参数 -- association propertyuser columnuser_id selectcom.example.mapper.UserMapper.selectById/ collection propertyitemList columnid selectcom.example.mapper.OrderItemMapper.selectByOrderId/ /resultMap select idselectOrderById resultMapOrderDetailMapBySelect SELECT * FROM order WHERE id #{orderId} /select!-- UserMapper.xml -- select idselectById resultTypeUser SELECT * FROM user WHERE id #{userId} /select!-- OrderItemMapper.xml -- resultMap idOrderItemDetailMap typeOrderItem association propertyproduct columnproduct_id selectcom.example.mapper.ProductMapper.selectById/ /resultMap select idselectByOrderId resultMapOrderItemDetailMap SELECT * FROM order_item WHERE order_id #{orderId} /select核心机制与巨坑执行流程MyBatis先执行selectOrderById得到Order的基础字段。然后对于association它取出结果中的user_id值去执行UserMapper.selectById查询并将结果设置到Order.user属性。对于collection它取出order.id值去执行OrderItemMapper.selectByOrderId查询出ListOrderItem。注意在查询OrderItem时又会触发其内部的association property”product”再去执行一次ProductMapper.selectById。经典的N1问题假设查询1个Order它有5个OrderItem。那么总共执行的SQL是1查Order 1查User 5查每个OrderItem 5查每个OrderItem对应的Product 12条。如果查询10个订单这个数字会爆炸式增长。这是嵌套查询模式最致命的缺点。fetchType”lazy”真的有用吗你可以在association或collection上添加fetchType”lazy”来尝试懒加载。但请注意一个大前提懒加载依赖于代理对象。如果当前会话SqlSession在数据加载完成前就被关闭了那么当你后续尝试访问懒加载属性时会抛出LazyInitializationException。在Web项目中这通常意味着你需要使用Open Session In View模式或在Service层手动控制会话生命周期这本身又带来了复杂性和争议。另外对于collection即使设置了lazyMyBatis在3.4.6之前版本也存在立即加载的Bug需要留意版本。如何选择没有银弹。对于管理后台、数据导出等需要完整数据的场景且数据量可控使用嵌套结果映射联表更高效。对于API接口可能只需要部分字段或者关联层级很深使用嵌套查询并结合懒加载和**Transactional** 注解确保会话存在更灵活。但务必对N1问题保持警惕。3.collection一对多把主键变成集合的纽带理解了associationcollection就很容易了。它处理的是一个对象包含另一个对象的集合。核心难点在于结果集的“行”到Java对象“集合”的转换。3.1 使用嵌套结果映射处理一对多继续用上面的联查SQL关键在于collection标签的配置。resultMap idOrderDetailMap typeOrder id propertyid columnorder_id/ !-- ... 其他基础字段和association ... -- !-- 一对多核心是ofType和子映射 -- collection propertyitemList ofTypeOrderItem resultMaporderItemMap/ /resultMapMyBatis的智能之处在于它会根据id标签此处是order_id来识别哪些行属于同一个Order。它会将order_id相同的所有行归组并为这个Order实例创建一个ListOrderItem。对于每一行它使用orderItemMap来构建一个OrderItem对象并添加到集合中。实操心得id标签的重要性在定义resultMap时必须为最外层对象这里是Order指定id。这个id不仅是主键映射更是MyBatis在内存中识别“同一行数据”或者说“同一个父对象”的关键。如果省略idMyBatis可能会将每一行数据库结果都当作一个新的Order对象导致返回的List中包含大量重复的Order仅itemList不同这绝对是灾难性的错误。我曾排查过一个性能问题查询返回了上万条数据内存飙升最后发现就是某个同事在复杂的resultMap里漏写了id。3.2 应对复杂集合映射鉴别器与自定义处理有时一个集合里可能包含不同类型的子对象。例如一个通知列表可能有TextNotice、ImageNotice等子类。这时可以使用discriminator鉴别器。resultMap idNoticeResultMap typeBaseNotice id propertyid columnid/ discriminator javaTypeint columntype case value1 resultMapTextNoticeMap/ case value2 resultMapImageNoticeMap/ /discriminator /resultMap resultMap idTextNoticeMap typeTextNotice extendsNoticeResultMap result propertycontent columncontent/ /resultMap但更常见的复杂场景是你不需要查询所有关联数据。比如只查询订单及其已支付的订单项。在联表查询中你可以在SQL的JOIN条件或WHERE子句中添加oi.status ‘PAID’。但在嵌套查询中你需要给collection的select方法传递多个参数。collection propertyitemList column{orderIdid, statusPAID} selectcom.example.mapper.OrderItemMapper.selectByOrderIdAndStatus/这里column”{orderIdid, statusPAID}”表示将当前结果行的id列值作为参数orderId和一个固定值’PAID’作为参数status传递给指定的select方法。4. 高级场景与性能优化实战掌握了基础用法我们来看看那些搜索热词里反映出的真实痛点。4.1 热词解析“开启事务后MyBatis一级缓存导致数据查询不到”这是一个非常经典的坑。MyBatis的一级缓存本地缓存默认是开启的其作用域是同一个SqlSession。在同一个事务通常对应一个SqlSession中如果你执行了两次完全相同的查询相同的SQL和参数MyBatis默认会从一级缓存中直接返回第一次查询的结果对象而不是去数据库查询。问题场景在Service方法上加了Transactional。方法内先执行updateOrder(order)更新了订单状态。紧接着又执行selectOrderById(orderId)想获取最新的订单数据。结果发现查询返回的还是更新前的旧数据原因更新操作会清空缓存但仅限于当前SqlSession中该语句映射的缓存。然而selectOrderById的缓存依然存在。由于在同一个事务SqlSession内第二次查询命中了缓存直接返回了旧对象。解决方案最直接在查询语句上设置flushCache”true”强制清空缓存并查询数据库。但这是全局影响需谨慎。select idselectOrderById resultMap... flushCachetrue更精细在查询前手动调用sqlSession.clearCache()清空当前会话的一级缓存。设计规避将读操作和写操作分离。对于需要强一致性的读取可以考虑不在同一个事务中或者使用不同的SqlSession。在Spring中可以通过Transactional(propagation Propagation.REQUIRES_NEW)开启一个新事务即新的SqlSession来读取。理解本质一级缓存是为了提升性能但在读写混合的场景下可能带来数据不一致的视图。对于需要实时性的数据要有意识地绕过缓存。4.2 热词解析“MyBatis查询Mapkey为主键value为对象”这个需求很常见例如查询一批商品返回一个MapLong, Product其中key是商品IDvalue是商品对象。MyBatis原生支持。!-- 接口方法MapLong, Product selectProductMapByIds(Param(ids) ListLong ids); -- select idselectProductMapByIds resultTypeProduct SELECT * FROM product WHERE id IN foreach collectionids itemid open( separator, close) #{id} /foreach /select关键在于在Mapper接口中返回值类型定义为MapLong, Product并且MyBatis要求查询结果中必须有一个属性可以作为Map的key。默认情况下它会使用实体类的MapKey注解指定的属性或者如果没有注解则尝试用第一个属性这不可靠。最稳妥的方式是使用MapKey注解MapKey(id) // 指定用Product对象的id属性作为Map的key MapLong, Product selectProductMapByIds(Param(ids) ListLong ids);那么这个功能和关联映射有什么关系想象一个场景你已经通过OrderItemMapper查出了一批OrderItem每个OrderItem里有一个product_id。现在你需要为这些OrderItem填充product对象。一种低效的做法是在collection的嵌套查询里为每个product_id单独查一次。更高效的做法是先批量收集所有需要的product_id。用上面selectProductMapByIds方法一次查询得到一个MapLong, Product。在Java代码中遍历OrderItem列表从Map里取出对应的Product对象手动设置进去。ListOrderItem items orderItemMapper.selectByOrderIds(orderIds); SetLong productIds items.stream().map(OrderItem::getProductId).collect(Collectors.toSet()); if (!productIds.isEmpty()) { MapLong, Product productMap productMapper.selectProductMapByIds(new ArrayList(productIds)); items.forEach(item - item.setProduct(productMap.get(item.getProductId()))); }这种方式完全避免了N1查询是处理批量数据关联时非常有效的手动优化策略。它打破了必须依赖MyBatis自动映射的思维定式。4.3 热词延伸MyBatis-Plus与关联查询很多项目使用MyBatis-PlusMP来简化单表CRUD。但MP本身并不直接提供对association和collection的增强支持。你依然需要自己编写XML和resultMap。MP的TableField注解中有exist false属性可以用来标记非数据库字段如user、itemList避免MP在自动构建SQL时包含它们。当你想从MyBatis 3.5.3升级到3.7.x时官方发布说明中一般会强调兼容性。对于关联映射部分需要重点测试嵌套查询的懒加载行为、鉴别器的解析以及复杂类型处理器是否正常工作。建议在测试环境充分回归测试所有包含复杂resultMap的查询。5. 设计哲学何时用关联映射何时应该放弃经过上面的分析你会发现MyBatis的关联映射是一把双刃剑。它提供了对象化查询的便利但也引入了性能复杂度。在我的经验里遵循以下原则能帮你做出更好的设计决策简单核心复杂边缘对于核心、高频的查询路径如C端订单详情页尽量保持简单。可以使用联表查询的resultMap但要严格控制关联的深度最好不超过3层。对于管理后台、数据导出等低频复杂查询可以适当使用嵌套查询并利用懒加载。拒绝“超级”ResultMap不要试图创建一个“万能”的OrderDetailMap企图一次查询出订单的所有信息用户、地址、订单项、商品、物流、优惠券……。这会导致SQL难以维护且任何地方调用这个查询都会产生巨大的性能开销。应该根据不同的业务场景定义多个精细化的ResultMap例如OrderSimpleMap、OrderWithUserMap、OrderWithItemsMap。拥抱“多次查询”与“内存组装”这是对抗复杂关联和N1问题的终极武器。就像上面“Map查询”的例子所示先分多次单表查询这些查询可以利用数据库索引非常高效然后在Service层或Mapper层用Java代码进行内存中的对象组装。这种方法清晰每个Mapper方法职责单一。可复用基础的单表查询可以被很多场景复用。易优化可以方便地引入批量查询如WHERE id IN (...)来减少查询次数。易缓存单表结果更容易被二级缓存如Redis命中。明确边界DTO出场当前端需要的数据和数据库的领域模型差异很大时不要强行扭曲resultMap。应该为API接口定义专门的DTOData Transfer Object并在Service层进行数据组装和转换。MyBatis也可以直接查询映射到DTO这比映射到复杂的领域对象再转换要高效得多。回到开头的问题为什么会出现“查不到”或“查太多”根本原因是我们混淆了数据库关系模型和业务对象模型。MyBatis的关联映射是连接两者的桥梁但这座桥怎么走需要根据实际的数据量、性能要求、网络开销和对象复杂度来精心设计。它不是一个可以无脑使用的“自动”功能而是一个需要开发者深刻理解其原理和代价的“手动”工具。下次当你写下collection或association时不妨先问自己我真的需要在这里关联吗有没有更简单、更清晰的方式 MyBatis关联映射实战：从核心原理到性能优化与避坑指南
1. 从“查不到”到“查太多”MyBatis关联映射的实战困境如果你用过MyBatis大概率遇到过这两种让人头疼的情况第一种你明明在数据库里看到订单下面有好几条明细但用MyBatis查出来的Order对象它的orderItemList属性却是个空的List你对着日志里打印的SQL看了半天数据都对但就是映射不上。第二种情况更常见你只是想查一个用户的基本信息结果MyBatis给你返回了一个嵌套了好几层的“巨无霸”对象里面包含了用户的所有订单订单里又包含了所有商品详情商品详情里还包含了供应商信息……一次简单的查询背后可能执行了N1条SQL性能瞬间跌入谷底。这两种极端恰恰是MyBatis处理数据关联时最核心的两个概念没搞透的典型表现一对多collection和多对一association。很多人把它们当成简单的配置标签照着网上的例子抄一遍能跑通就以为掌握了。但一到生产环境面对复杂的业务模型和性能要求各种诡异的问题就冒出来了数据映射不全、循环依赖、懒加载失效甚至是开头提到的“开启事务后一级缓存导致查询不到最新数据”这种深坑。今天我们不聊那些干巴巴的概念定义。我想从一个资深开发踩过坑的角度带你重新理解collection和association。我会通过一个贯穿始终的电商案例用户-订单-订单项-商品手把手拆解如何从零构建清晰的关联映射并重点分享那些官方文档里不会写但在真实项目中绕不开的性能陷阱、设计取舍和排查技巧。比如为什么有时候你宁愿写多条单独的查询也不要用一个复杂的联查fetchType”lazy”真的能“懒”起来吗面对“MyBatis查询Mapkey为主键value为对象”这种特定需求关联映射又该如何配合理解了这些你不仅能写出正确的映射更能写出高效、可维护的映射。2. 关联映射的核心不是“联表”而是“对象组装”在深入标签之前我们必须扭转一个常见的误解MyBatis的关联映射其首要目的不是为了写出一个多表连接的复杂SQL而是为了在Java对象层面构建出符合业务语义的领域模型。2.1 场景定义一个经典的电商模型假设我们有四张表user用户表有id,username等字段。order订单表有id,order_no,user_id外键,amount等字段。order_item订单项表有id,order_id外键,product_id外键,quantity,price等字段。product商品表有id,product_name,stock等字段。对应的Java实体类使用Lombok简化// 用户 Data public class User { private Long id; private String username; // 一个用户有多个订单 private ListOrder orderList; } // 订单 Data public class Order { private Long id; private String orderNo; private BigDecimal amount; // 多对一一个订单属于一个用户 private User user; // 一对多一个订单有多个订单项 private ListOrderItem itemList; } // 订单项 Data public class OrderItem { private Long id; private Integer quantity; private BigDecimal price; // 多对一一个订单项属于一个订单 private Order order; // 多对一一个订单项对应一个商品 private Product product; } // 商品 Data public class Product { private Long id; private String productName; private Integer stock; }我们的目标是通过MyBatis在查询Order时能方便地获取到对应的User信息和OrderItem列表并且在OrderItem中能获取到Product详情。这就是典型的“多对一”和“一对多”嵌套。2.2association多对一把外键变成对象属性association用于映射“有一个”的关系即当前对象包含另一个对象的引用。在订单对象中user属性就是一个典型的“多对一”关联。最常见的错误做法在OrderMapper.xml里直接写一个四表连接的超级SQL然后指望MyBatis自动把结果集塞进嵌套的对象里。这会导致SQL极其复杂且难以复用。推荐的做法分步查询与嵌套结果映射。MyBatis提供了两种主要方式。方式一嵌套结果映射单SQL联表查询这种方式适合关联关系简单、数据量不大的场景。!-- OrderMapper.xml -- resultMap idOrderDetailMap typeOrder id propertyid columnorder_id/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 多对一映射关联用户 -- association propertyuser javaTypeUser id propertyid columnuser_id/ result propertyusername columnusername/ !-- 注意如果user还有orderList这里不要映射否则会造成循环 -- /association !-- 一对多映射关联订单项集合稍后详细讲 -- collection propertyitemList ofTypeOrderItem resultMaporderItemMap/ /resultMap !-- 专门定义OrderItem的映射避免重复 -- resultMap idorderItemMap typeOrderItem id propertyid columnitem_id/ result propertyquantity columnquantity/ result propertyprice columnprice/ !-- 订单项关联商品又是一个多对一 -- association propertyproduct javaTypeProduct id propertyid columnproduct_id/ result propertyproductName columnproduct_name/ /association /resultMap select idselectOrderWithDetails resultMapOrderDetailMap SELECT o.id as order_id, o.order_no, o.amount, u.id as user_id, u.username, oi.id as item_id, oi.quantity, oi.price, p.id as product_id, p.product_name FROM order o LEFT JOIN user u ON o.user_id u.id LEFT JOIN order_item oi ON o.id oi.order_id LEFT JOIN product p ON oi.product_id p.id WHERE o.id #{orderId} /select关键点与坑列别名是生命线联表查询必然有重复列名如多个id。必须为每个列起唯一的别名as order_id,as user_id并在resultMap中通过column属性精确指定否则数据会错乱映射。循环引用警告在上面的association property”user”里我们只映射了User的id和username故意没有映射User的orderList属性。如果映射了当MyBatis组装Order对象其user属性指向一个User对象而这个User对象的orderList又包含当前Order对象就会形成死循环导致序列化比如转JSON时栈溢出。这是设计领域模型和结果映射时必须警惕的。性能考量这条SQL通过三次LEFT JOIN一次性取出所有数据。如果订单有10个订单项结果集就会返回10行订单和用户的信息会重复10次。对于数据量大的情况网络传输和内存解析会有压力。方式二嵌套查询分步查询N1问题之源这种方式更符合“单一职责”每个Mapper只关心自己的数据。!-- OrderMapper.xml -- resultMap idOrderDetailMapBySelect typeOrder id propertyid columnid/ result propertyorderNo columnorder_no/ result propertyamount columnamount/ !-- 通过select属性指定另一个Mapper的查询方法column指定传递的参数 -- association propertyuser columnuser_id selectcom.example.mapper.UserMapper.selectById/ collection propertyitemList columnid selectcom.example.mapper.OrderItemMapper.selectByOrderId/ /resultMap select idselectOrderById resultMapOrderDetailMapBySelect SELECT * FROM order WHERE id #{orderId} /select!-- UserMapper.xml -- select idselectById resultTypeUser SELECT * FROM user WHERE id #{userId} /select!-- OrderItemMapper.xml -- resultMap idOrderItemDetailMap typeOrderItem association propertyproduct columnproduct_id selectcom.example.mapper.ProductMapper.selectById/ /resultMap select idselectByOrderId resultMapOrderItemDetailMap SELECT * FROM order_item WHERE order_id #{orderId} /select核心机制与巨坑执行流程MyBatis先执行selectOrderById得到Order的基础字段。然后对于association它取出结果中的user_id值去执行UserMapper.selectById查询并将结果设置到Order.user属性。对于collection它取出order.id值去执行OrderItemMapper.selectByOrderId查询出ListOrderItem。注意在查询OrderItem时又会触发其内部的association property”product”再去执行一次ProductMapper.selectById。经典的N1问题假设查询1个Order它有5个OrderItem。那么总共执行的SQL是1查Order 1查User 5查每个OrderItem 5查每个OrderItem对应的Product 12条。如果查询10个订单这个数字会爆炸式增长。这是嵌套查询模式最致命的缺点。fetchType”lazy”真的有用吗你可以在association或collection上添加fetchType”lazy”来尝试懒加载。但请注意一个大前提懒加载依赖于代理对象。如果当前会话SqlSession在数据加载完成前就被关闭了那么当你后续尝试访问懒加载属性时会抛出LazyInitializationException。在Web项目中这通常意味着你需要使用Open Session In View模式或在Service层手动控制会话生命周期这本身又带来了复杂性和争议。另外对于collection即使设置了lazyMyBatis在3.4.6之前版本也存在立即加载的Bug需要留意版本。如何选择没有银弹。对于管理后台、数据导出等需要完整数据的场景且数据量可控使用嵌套结果映射联表更高效。对于API接口可能只需要部分字段或者关联层级很深使用嵌套查询并结合懒加载和**Transactional** 注解确保会话存在更灵活。但务必对N1问题保持警惕。3.collection一对多把主键变成集合的纽带理解了associationcollection就很容易了。它处理的是一个对象包含另一个对象的集合。核心难点在于结果集的“行”到Java对象“集合”的转换。3.1 使用嵌套结果映射处理一对多继续用上面的联查SQL关键在于collection标签的配置。resultMap idOrderDetailMap typeOrder id propertyid columnorder_id/ !-- ... 其他基础字段和association ... -- !-- 一对多核心是ofType和子映射 -- collection propertyitemList ofTypeOrderItem resultMaporderItemMap/ /resultMapMyBatis的智能之处在于它会根据id标签此处是order_id来识别哪些行属于同一个Order。它会将order_id相同的所有行归组并为这个Order实例创建一个ListOrderItem。对于每一行它使用orderItemMap来构建一个OrderItem对象并添加到集合中。实操心得id标签的重要性在定义resultMap时必须为最外层对象这里是Order指定id。这个id不仅是主键映射更是MyBatis在内存中识别“同一行数据”或者说“同一个父对象”的关键。如果省略idMyBatis可能会将每一行数据库结果都当作一个新的Order对象导致返回的List中包含大量重复的Order仅itemList不同这绝对是灾难性的错误。我曾排查过一个性能问题查询返回了上万条数据内存飙升最后发现就是某个同事在复杂的resultMap里漏写了id。3.2 应对复杂集合映射鉴别器与自定义处理有时一个集合里可能包含不同类型的子对象。例如一个通知列表可能有TextNotice、ImageNotice等子类。这时可以使用discriminator鉴别器。resultMap idNoticeResultMap typeBaseNotice id propertyid columnid/ discriminator javaTypeint columntype case value1 resultMapTextNoticeMap/ case value2 resultMapImageNoticeMap/ /discriminator /resultMap resultMap idTextNoticeMap typeTextNotice extendsNoticeResultMap result propertycontent columncontent/ /resultMap但更常见的复杂场景是你不需要查询所有关联数据。比如只查询订单及其已支付的订单项。在联表查询中你可以在SQL的JOIN条件或WHERE子句中添加oi.status ‘PAID’。但在嵌套查询中你需要给collection的select方法传递多个参数。collection propertyitemList column{orderIdid, statusPAID} selectcom.example.mapper.OrderItemMapper.selectByOrderIdAndStatus/这里column”{orderIdid, statusPAID}”表示将当前结果行的id列值作为参数orderId和一个固定值’PAID’作为参数status传递给指定的select方法。4. 高级场景与性能优化实战掌握了基础用法我们来看看那些搜索热词里反映出的真实痛点。4.1 热词解析“开启事务后MyBatis一级缓存导致数据查询不到”这是一个非常经典的坑。MyBatis的一级缓存本地缓存默认是开启的其作用域是同一个SqlSession。在同一个事务通常对应一个SqlSession中如果你执行了两次完全相同的查询相同的SQL和参数MyBatis默认会从一级缓存中直接返回第一次查询的结果对象而不是去数据库查询。问题场景在Service方法上加了Transactional。方法内先执行updateOrder(order)更新了订单状态。紧接着又执行selectOrderById(orderId)想获取最新的订单数据。结果发现查询返回的还是更新前的旧数据原因更新操作会清空缓存但仅限于当前SqlSession中该语句映射的缓存。然而selectOrderById的缓存依然存在。由于在同一个事务SqlSession内第二次查询命中了缓存直接返回了旧对象。解决方案最直接在查询语句上设置flushCache”true”强制清空缓存并查询数据库。但这是全局影响需谨慎。select idselectOrderById resultMap... flushCachetrue更精细在查询前手动调用sqlSession.clearCache()清空当前会话的一级缓存。设计规避将读操作和写操作分离。对于需要强一致性的读取可以考虑不在同一个事务中或者使用不同的SqlSession。在Spring中可以通过Transactional(propagation Propagation.REQUIRES_NEW)开启一个新事务即新的SqlSession来读取。理解本质一级缓存是为了提升性能但在读写混合的场景下可能带来数据不一致的视图。对于需要实时性的数据要有意识地绕过缓存。4.2 热词解析“MyBatis查询Mapkey为主键value为对象”这个需求很常见例如查询一批商品返回一个MapLong, Product其中key是商品IDvalue是商品对象。MyBatis原生支持。!-- 接口方法MapLong, Product selectProductMapByIds(Param(ids) ListLong ids); -- select idselectProductMapByIds resultTypeProduct SELECT * FROM product WHERE id IN foreach collectionids itemid open( separator, close) #{id} /foreach /select关键在于在Mapper接口中返回值类型定义为MapLong, Product并且MyBatis要求查询结果中必须有一个属性可以作为Map的key。默认情况下它会使用实体类的MapKey注解指定的属性或者如果没有注解则尝试用第一个属性这不可靠。最稳妥的方式是使用MapKey注解MapKey(id) // 指定用Product对象的id属性作为Map的key MapLong, Product selectProductMapByIds(Param(ids) ListLong ids);那么这个功能和关联映射有什么关系想象一个场景你已经通过OrderItemMapper查出了一批OrderItem每个OrderItem里有一个product_id。现在你需要为这些OrderItem填充product对象。一种低效的做法是在collection的嵌套查询里为每个product_id单独查一次。更高效的做法是先批量收集所有需要的product_id。用上面selectProductMapByIds方法一次查询得到一个MapLong, Product。在Java代码中遍历OrderItem列表从Map里取出对应的Product对象手动设置进去。ListOrderItem items orderItemMapper.selectByOrderIds(orderIds); SetLong productIds items.stream().map(OrderItem::getProductId).collect(Collectors.toSet()); if (!productIds.isEmpty()) { MapLong, Product productMap productMapper.selectProductMapByIds(new ArrayList(productIds)); items.forEach(item - item.setProduct(productMap.get(item.getProductId()))); }这种方式完全避免了N1查询是处理批量数据关联时非常有效的手动优化策略。它打破了必须依赖MyBatis自动映射的思维定式。4.3 热词延伸MyBatis-Plus与关联查询很多项目使用MyBatis-PlusMP来简化单表CRUD。但MP本身并不直接提供对association和collection的增强支持。你依然需要自己编写XML和resultMap。MP的TableField注解中有exist false属性可以用来标记非数据库字段如user、itemList避免MP在自动构建SQL时包含它们。当你想从MyBatis 3.5.3升级到3.7.x时官方发布说明中一般会强调兼容性。对于关联映射部分需要重点测试嵌套查询的懒加载行为、鉴别器的解析以及复杂类型处理器是否正常工作。建议在测试环境充分回归测试所有包含复杂resultMap的查询。5. 设计哲学何时用关联映射何时应该放弃经过上面的分析你会发现MyBatis的关联映射是一把双刃剑。它提供了对象化查询的便利但也引入了性能复杂度。在我的经验里遵循以下原则能帮你做出更好的设计决策简单核心复杂边缘对于核心、高频的查询路径如C端订单详情页尽量保持简单。可以使用联表查询的resultMap但要严格控制关联的深度最好不超过3层。对于管理后台、数据导出等低频复杂查询可以适当使用嵌套查询并利用懒加载。拒绝“超级”ResultMap不要试图创建一个“万能”的OrderDetailMap企图一次查询出订单的所有信息用户、地址、订单项、商品、物流、优惠券……。这会导致SQL难以维护且任何地方调用这个查询都会产生巨大的性能开销。应该根据不同的业务场景定义多个精细化的ResultMap例如OrderSimpleMap、OrderWithUserMap、OrderWithItemsMap。拥抱“多次查询”与“内存组装”这是对抗复杂关联和N1问题的终极武器。就像上面“Map查询”的例子所示先分多次单表查询这些查询可以利用数据库索引非常高效然后在Service层或Mapper层用Java代码进行内存中的对象组装。这种方法清晰每个Mapper方法职责单一。可复用基础的单表查询可以被很多场景复用。易优化可以方便地引入批量查询如WHERE id IN (...)来减少查询次数。易缓存单表结果更容易被二级缓存如Redis命中。明确边界DTO出场当前端需要的数据和数据库的领域模型差异很大时不要强行扭曲resultMap。应该为API接口定义专门的DTOData Transfer Object并在Service层进行数据组装和转换。MyBatis也可以直接查询映射到DTO这比映射到复杂的领域对象再转换要高效得多。回到开头的问题为什么会出现“查不到”或“查太多”根本原因是我们混淆了数据库关系模型和业务对象模型。MyBatis的关联映射是连接两者的桥梁但这座桥怎么走需要根据实际的数据量、性能要求、网络开销和对象复杂度来精心设计。它不是一个可以无脑使用的“自动”功能而是一个需要开发者深刻理解其原理和代价的“手动”工具。下次当你写下collection或association时不妨先问自己我真的需要在这里关联吗有没有更简单、更清晰的方式