Mybatis使用collection分頁問題舉例分析

本篇內容介紹了“Mybatis使用collection分頁問題舉例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

原因

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

方案

方案一

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

這種方式雖然很簡單，但在大型數(shù)據(jù)集或大型數(shù)據(jù)表上表現(xiàn)不佳。這個問題被稱為“N+1 查詢問題”。 概括地講，N+1 查詢問題是這樣子的：

你執(zhí)行了一個單獨的 SQL 語句來獲取結果的一個列表（就是“+1”）。對列表返回的每條記錄，你執(zhí)行一個 select 查詢語句來為每條記錄加載詳細信息（就是“N”）。

這個問題會導致成百上千的 SQL 語句被執(zhí)行。有時候，我們不希望產(chǎn)生這樣的后果。

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

方案二

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

擴展

Mybatis中配置加載一對多關系的兩種方式：

1.集合的嵌套 Select 查詢

一共會產(chǎn)生兩個SQL語句，一個查詢主的數(shù)據(jù)，另一個查詢關聯(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.集合的嵌套結果映射

只會產(chǎn)品一個SQL語句，主數(shù)據(jù)以及關聯(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>

“Mybatis使用collection分頁問題舉例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！