使用MyBatis查询数据时，多独立select和合并单select哪种方式更优？

独立单查询方案（多select方法） #

• 核心优势
  • 可维护性拉满：每个查询方法职责唯一，后续调整单个查询逻辑、复用某段查询能力时，不需要修改其他关联逻辑，出错概率极低。排查问题也能直接定位到对应SQL，不用拆解复杂的嵌套语句。
  • 缓存配置灵活：可以单独为高频查询配置MyBatis一/二级缓存，不会因为某一个查询逻辑变动导致所有关联查询的缓存整体失效。
• 劣势
  • 会产生多次数据库请求，存在多轮网络RTT开销。不过现在Java项目几乎都会配置HikariCP这类高性能连接池，连接复用的前提下，多次查询的额外开销其实远低于普遍预期，只有当单次接口需要查询10个以上完全独立的表时，累计开销才会有明显感知。

合并嵌套查询方案（单select包含多子查询） #

• 核心优势
  • 仅需要一次数据库请求，网络开销更低。如果查询数量在2-3个以内、所有子查询逻辑稳定、执行速度快的场景下，整体接口耗时会更优。
• 劣势
  • 维护成本非常高：只要其中一个子查询需要调整逻辑，就要修改整个大SQL，很容易误改其他部分；嵌套子查询的可读性也很差，新接手的团队成员梳理逻辑的成本会高很多。
  • 性能天花板低：如果后续某一个子查询的数据量上涨、或者需要新增关联逻辑，很容易导致整个SQL性能骤降，优化难度远高于单独优化小SQL。
  • 缓存灵活性差：只要任意一个子查询对应的数据发生变更，整个大查询的缓存就要整体失效，无法单独复用高频子查询的缓存结果。

实际开发选型建议 #

• 仅当满足「查询数量≤3个、所有子查询逻辑长期不会变动、子查询性能稳定」这几个条件时，优先选合并嵌套查询方案。
• 其余绝大多数场景，优先选独立单查询方案：
  • 担心多次请求开销的话，可以开启MyBatis批量执行器，或者通过SqlSession将多个查询打包在同一会话中执行，开销和单次查询差距极小。
  • 后续真的出现性能瓶颈时，再针对性做优化，比如给慢查询加缓存、将几个稳定的小查询合并，比一开始就写死复杂大SQL的灵活度高很多。

内容的提问来源于stack exchange，提问作者Julia5049