項目中mybatis分頁的場景是非常高頻的，當(dāng)使用ResultMap并配置collection做分頁的時候，我們可能會遇到獲取當(dāng)前頁的數(shù)據(jù)少于每頁大小的數(shù)據(jù)問題。接下來通過本文給大家介紹Mybatis使用collection分頁問題，感興趣的朋友一起看看吧

原因

引起該問題的原因是當(dāng)我們使用的是ResultMap集合的嵌套結(jié)果映射來處理通過join查詢的結(jié)果集，映射成Java實體類型的時候，會導(dǎo)致主數(shù)據(jù)被映射折疊后少于從數(shù)據(jù)庫獲取的數(shù)據(jù)，從而導(dǎo)致獲取的映射數(shù)據(jù)少于每頁大小的數(shù)據(jù)。

方案

方案一

不使用集合的嵌套結(jié)果映射，使用集合的嵌套select查詢解決。使用該方案需要注意性能問題，會導(dǎo)致“N+1查詢問題”。

這種方式雖然很簡單，但在大型數(shù)據(jù)集或大型數(shù)據(jù)表上表現(xiàn)不佳。這個問題被稱為“N+1 查詢問題”。概括地講，N+1 查詢問題是這樣子的：
你執(zhí)行了一個單獨的 SQL 語句來獲取結(jié)果的一個列表（就是“+1”）。對列表返回的每條記錄，你執(zhí)行一個 select 查詢語句來為每條記錄加載詳細信息（就是“N”）。
這個問題會導(dǎo)致成百上千的 SQL 語句被執(zhí)行。有時候，我們不希望產(chǎn)生這樣的后果。

好消息是，MyBatis 能夠?qū)@樣的查詢進行延遲加載，因此可以將大量語句同時運行的開銷分散開來。然而，如果你加載記錄列表之后立刻就遍歷列表以獲取嵌套的數(shù)據(jù)，就會觸發(fā)所有的延遲加載查詢，性能可能會變得很糟糕。

方案二

移除collection配置，在業(yè)務(wù)邏輯中進行處理。先將參與分頁的數(shù)據(jù)獲取出來，再根據(jù)需要在業(yè)務(wù)代碼中獲取分頁數(shù)據(jù)關(guān)聯(lián)的數(shù)據(jù)。博主更傾向于這種方案解決mybatis中collection分頁問題。

擴展

Mybatis中配置加載一對多關(guān)系的兩種方式：

1.集合的嵌套 Select 查詢

一共會產(chǎn)生兩個SQL語句，一個查詢主的數(shù)據(jù)，另一個查詢關(guān)聯(lián)的數(shù)據(jù)。如下所示：

<resultMap id="blogResult" type="Blog">
  <collection property="posts" javaType="ArrayList" column="id" ofType="Post" select="selectPostsForBlog"/>
</resultMap>
 
<select id="selectBlog" resultMap="blogResult">
  SELECT * FROM BLOG WHERE ID = #{id}
</select>
 
<select id="selectPostsForBlog" resultType="Post">
  SELECT * FROM POST WHERE BLOG_ID = #{id}
</select>

2.集合的嵌套結(jié)果映射

只會產(chǎn)品一個SQL語句，主數(shù)據(jù)以及關(guān)聯(lián)數(shù)據(jù)通過別名的形式進行配置映射到各自的對象的屬性上。入戲所示：

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <collection property="posts" ofType="Post" resultMap="blogPostResult" columnPrefix="post_"/>
</resultMap>
 
<resultMap id="blogPostResult" type="Post">
  <id property="id" column="id"/>
  <result property="subject" column="subject"/>
  <result property="body" column="body"/>
</resultMap>