前言：一張關聯(lián)表，讓你頭禿了嗎？

你是不是也寫過這種需求：

• 查詢某個用戶及其角色列表
• 查詢訂單及明細
• 查詢項目及其下屬的多個階段和負責人

最后寫了一堆復雜 SQL + resultMap，運行一看，要么數(shù)據(jù)重復、要么數(shù)據(jù)丟失，最慘還可能觸發(fā) N+1 查詢……

其實問題不是 MyBatis 不行，而是你用的方法不對。

?? 三種最常見的寫法 

? 方式一：聯(lián)表查詢 + 扁平映射（推薦）

這是我最常用也最穩(wěn)定的一種方式：寫一條聯(lián)表 SQL，把需要的字段都查出來，返回扁平結構，再在 Java 層進行組裝。

示例 SQL：

SELECT u.id AS userId, u.name AS userName,
       r.id AS roleId, r.name AS roleName
FROM user u
LEFT JOIN user_role ur ON u.id = ur.user_id
LEFT JOIN role r ON ur.role_id = r.id

特點：

• 一條 SQL 查全所有數(shù)據(jù)；
• 性能高，邏輯直觀；
• 可與分頁插件（如 PageHelper）完美配合。

我的建議：

Java 層用 Map<Long, UserDTO> 分組封裝，適合在 Service 層統(tǒng)一做聚合邏輯。

?? 方式二：嵌套結果（resultMap + collection）

適合結構較為清晰的“樹狀結構”，比如訂單和訂單項、項目和子模塊。

示例 XML： 

<resultMap id="userMap" type="User">
  <id property="id" column="user_id"/>
  <result property="name" column="user_name"/>
  <collection property="roles" ofType="Role">
    <id property="id" column="role_id"/>
    <result property="name" column="role_name"/>
  </collection>
</resultMap>

特點：

• 多表映射層級清晰；
• 比較適合中小型數(shù)據(jù)量。

踩坑經驗：

• 寫錯列名字段，就會導致內層集合全是 null；
• 出現(xiàn)重復數(shù)據(jù)時，要手動去重或用 Set；
• 不適合配合分頁，容易導致“分頁的是主表，但集合是全量”。

?? 方式三：嵌套查詢（nested select）

適合邏輯解耦，按模塊維護的場景。

示例 XML：

<collection property="roles" ofType="Role" select="selectRolesByUserId" column="id"/>

特點：

• 每條主表數(shù)據(jù)觸發(fā)一次副查詢；
• 易維護但 極易 N+1；
• 不適合大批量數(shù)據(jù)查詢。

實戰(zhàn)建議：

除非你能保證每次最多查詢 10 條主記錄，否則慎用。性能瓶頸很容易出現(xiàn)在這里！

?? 你可能踩過的坑

? 實戰(zhàn)建議：如何選擇這三種方式？ 

?? 我的最佳實踐模板（真實項目用的）

• DAO 層只查數(shù)據(jù)，不做結構組裝；
• Service 層按業(yè)務模型拼裝 DTO；
• 多表結果不要直接給前端，統(tǒng)一封裝響應結構；
• DTO + Builder 模式 + Map 分組，靈活好用；

?? 總結一句話：

多表查詢選對方式，寫代碼少掉一半 bug。

不必糾結哪種方式最“完美”，關鍵是是否適合你當前場景。
記住：能用聯(lián)查查全的，就別搞子查詢；分頁場景盡量別用嵌套結構；小數(shù)據(jù)就圖方便，結構優(yōu)先。

到此這篇關于MyBatis 多表查詢的文章就介紹到這了,更多相關MyBatis 多表查詢內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論