MyBatis延遲加載策略深入探究

更新時間：2022年07月30日 08:46:22 作者：·~簡單就好

本文主要為大家詳細介紹下mybatis的延遲加載，從原理上介紹下怎么使用、有什么好處能規(guī)避什么問題。感興趣的小伙伴可以跟隨小編一起學習一下

分步查詢的優(yōu)點

**可以實現(xiàn)延遲加載，**但是必須在核心配置文件中設置全局配置信息

lazyLoadingEnabled:延遲加載的全局開關。當開啟時，所有關聯(lián)對象都會延遲加載

aggressiveLazyLoding:當開啟時，任何方式的調(diào)用都會加載該對象的所有屬性。否則，該屬性會按需加載，此時就可以實現(xiàn)按需加載，需要獲取的數(shù)據(jù)是什么，就只會執(zhí)行相應的sql.此時會通過association和collection中的fetchType屬性設置當前的分步查詢是否使用懶加載

fetchType=“lazy(延遲加載) | eager(立即加載)”

在主配置文件當中設置延遲加載

延遲加載：在SqlMapConfig.xml中配置延遲加載文件

<settings>
    <setting name="logImpl" value="STDOUT_LOGGING" />  <!-- 打印日志到控制臺上 -->
    <setting name="lazyLoadingEnabled" value="true"/>   
    <setting name="aggressiveLazyLoading" value="false"/>   <!-- false才會按需加載，不開啟調(diào)用所有的對象 -->
</settings>

在studentDao.xml當中設置分步查詢

測試結果

此時開啟了懶加載，實現(xiàn)了分布查詢

如何使用

public class UserDO {
  private Integer userId;
  private String username;
  private String password;
  private String nickname;
  private List<PermitDO> permitDOList;
  public UserDO() {}
}

<resultMap id="BaseMap" type="org.apache.ibatis.study.entity.UserDO">
    <id column="user_id" jdbcType="INTEGER" property="userId" />
    <result column="username" jdbcType="VARCHAR" property="username" />
    <result column="password" jdbcType="VARCHAR" property="password" />
    <result column="nickname" jdbcType="VARCHAR" property="nickname"/>
    <collection property="permitDOList" column="user_id" select="getPermitsByUserId"
     fetchType="lazy">
    </collection>
</resultMap>
  <resultMap id="PermitBaseMap" type="org.apache.ibatis.study.entity.PermitDO">
    <id column="id" jdbcType="INTEGER" property="id"/>
    <result column="code" jdbcType="VARCHAR" property="code"/>
    <result column="name" jdbcType="VARCHAR" property="name"/>
    <result column="type" jdbcType="TINYINT" property="type"/>
    <result column="pid" jdbcType="INTEGER" property="pid"/>
  </resultMap>
   <select id="getByUserId2" resultMap="BaseMap">
    select * from user
    where user_id = #{userId}
  </select>
  <select id="getPermitsByUserId" resultMap="PermitBaseMap">
    select p.*
    from user_permit up
    inner join permit p on up.permit_id = p.id
    where up.user_id = #{userId}
  </select>

通過fetchType=lazy指定子查詢getPermitsByUserId使用懶加載，這樣的話就不用管全局配置lazyLoadingEnabled是true還是false了。當然這里可以直接用多表關聯(lián)查詢不使用子查詢，使用方法在這篇文章

測試代碼

public class Test {
  public static void main(String[] args) throws IOException {
    try (InputStream inputStream = Resources.getResourceAsStream("mybatis-config.xml")) {
      // 構建session工廠 DefaultSqlSessionFactory
      SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
      SqlSession sqlSession = sqlSessionFactory.openSession();
      UserMapper userMapper = sqlSession.getMapper(UserMapper.class);
      UserDO userDO = userMapper.getByUserId2(1);
      System.out.println(userDO);
    }
  }
}

結果如下，打了斷點可以看到原userDO對象已被代理并且permitDOList是null需要調(diào)用get方法才會去查詢拿到值，咳咳這邊之前直接運行顯示是已經(jīng)把permitDOList查詢出來了,想了半天啥原因后來才發(fā)現(xiàn)println會調(diào)用userDO對象的toString方法，而toString方法也會走代理方法直接去調(diào)用子查詢的

延遲加載的好處

延遲加載主要能解決mybatis的N+1問題，什么是N+1問題其實叫1+N更為合理，以上面的業(yè)務例子來說就是假設一次查詢出來10000個用戶，那么還需要針對這10000個用戶使用子查詢getPermitsByUserId獲取每個用戶的權限列表，需要10000次查詢，總共10001次，真實情況下你可能并不需要每個子查詢的結果，這樣就浪費數(shù)據(jù)庫連接資源了。如果使用延遲加載的話就相當于不用進行這10000次查詢，因為它是等到你真正使用的時候才會調(diào)用子查詢獲取結果。

到此這篇關于MyBatis延遲加載策略深入探究的文章就介紹到這了,更多相關MyBatis延遲加載內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: