MyBatis的查询加载机制像是一位贴心的餐厅服务员——你可以选择让所有菜品一次性上齐，也可以根据用餐节奏逐道呈上。这种灵活性让数据访问变得优雅而高效。
1.1 MyBatis加载机制的基本概念
加载机制本质上决定了关联数据何时从数据库获取。想象你查询订单信息时，订单详情、客户资料这些关联数据就像隐藏在幕后的演员。MyBatis的加载机制就是导演，控制着这些演员何时登台亮相。
传统JDBC开发中，我们往往需要手动编写复杂的SQL联接查询。MyBatis通过配置化的方式，让关联数据的加载变得简单可控。这种设计哲学体现了框架对开发者的体贴——把复杂留给框架，把简单留给使用者。
我记得第一次使用MyBatis时，最让我惊喜的就是这种声明式的关联配置。不需要在代码里写冗长的JOIN查询，几个简单的XML配置就能实现相同效果。
1.2 立即加载与延迟加载的定义
立即加载像是个急性子——查询主对象时，所有关联对象一并加载。执行一个订单查询，订单项、收货地址、支付记录全部瞬间到位。这种方式的优点是数据完整，缺点是可能加载了不需要的数据。
延迟加载则像个精打细算的管家——只有真正访问关联属性时，才去执行对应的查询。点击查看订单详情时才加载订单项，查看物流信息时才查询配送记录。这种按需加载的模式，有效避免了不必要的数据传输。
两种加载策略各有性格。立即加载豪爽大方，延迟加载精打细算。选择哪种，完全取决于你的业务场景。
1.3 两种加载方式的适用场景对比
立即加载适合关联数据大概率会被使用的场景。比如电商平台的订单详情页，用户几乎总是需要看到订单项和价格信息。这种情况下一次性加载所有数据，反而能减少后续的数据库访问次数。
延迟加载在关联数据使用概率不确定时优势明显。社交媒体的用户信息查询，用户的粉丝列表、动态记录这些数据量大的关联信息，完全可以等到用户真正点击查看时再加载。
实际开发中，我倾向于根据数据的使用频率来做选择。高频使用的关联用立即加载，低频使用的用延迟加载。这种混合策略往往能取得最好的性能平衡。
MyBatis的灵活之处在于，你可以在全局配置中设定默认策略，也可以在具体关联中单独覆盖。这种细粒度的控制，让数据加载真正做到了收放自如。