[TOC] # 一對多 查詢type表的某一條數據，并且要同時查出所有typeid與之配置的user，最終要得到一個以下類型的Type對象 ~~~ public class Type { String id; String name; List<User> users; ~~~ **dao層** ~~~ @Select("select * from user where typeid = #{typeid}") public List<User> findUserById(String typeid); @Results({ @Result(property="id",column="id"), //users映射List<User> users，many=@Many是調用關聯查詢方法，"id"是關聯查詢條件，FetchType.LAZY是延遲加載 @Result(property="users",column="id", many=@Many(select="hello.dao.MybatisDao.findUserById",fetchType=FetchType.LAZY)) }) @Select("select * from type where id=#{id}") public Type findTypeById(String id); ~~~ 注意，如果省略第一個@Result, 查出來的type對象id是null，因為第二個@Result使用關聯查詢時把`column="id"`映射給了`property="users"`。 **service層** ~~~ Type type = mybatisDao.findTypeById("1"); System.out.println("延遲加載"); type.getUsers(); ~~~ 因為設置了`fetchType=FetchType.LAZY`，`mybatisDao.findTypeById("1")`只會查詢type表，當訪問type.getUsers()時才會查詢其關聯表。 # 其它關聯 一對一：把上面的`many=@Many`換成`one=@One`，其他原理是一樣的 多對多：把多個字段映射成`many=@Many`，就是多對多了 多對一：把上面dao方法的返回值從Type換成List # JAVA注解的局限性 通過SQL日志可以看到，前面的一對多關聯查詢實際上執行了兩次select，這就是hibernate中典型的n+1問題。 假設我現在type表中有三條記錄，我要查出所有的type及其對應的user對象，最終得到一個List，查詢過程是這樣的  一共執行了四次查詢，一次查type表，因為有三條記錄，所以查了三次user表，以此來填充三個type對象的List users屬性。 如果type表中有幾百條數據，而且還有上十個表進行關聯查詢，結果無法設想。 在傳統的xml配置方式中，是可以用一條SQL查出無限層嵌套的關聯關系的。不過mybatis官方做出了一個說明，由于java注解的局限性，不支持那種映射方式。 所以，如果想只用一條SQL查出關聯映射，必須借住xml. # xml無限層嵌套映射 這里以三層嵌套為例，以實現前端的三級菜單樹。這是一個tree表，pid是其上級菜單的id  要得到的查詢結果Tree對象，這個對象是可以無限遞歸的 ~~~ public class Tree { String id; String name; List<Tree> child; ~~~ **dao** ~~~ @Mapper public interface TreeDao { @ResultMap("tree") @Select("SELECT p1.id,p1.name,p2.id id2,p2.name name2,p3.id id3,p3.name name3 " + "FROM tree p1,tree p2,tree p3 WHERE p1.id=p2.pid AND p2.id=p3.pid") public List findTree(); ~~~ 這個SQL在數據庫中的查詢結果是這樣的，可以發現前四個字段是一樣的，而且都是冗余數據，如果用java注解的關聯查詢是不會這樣的  `@ResultMap("tree")`：映射結果集id是tree，前面說了，這個映射要在xml中配置 `application.properties`文件中添加配置 ~~~ #指定xml映射文件的路徑 mybatis.mapper-locations=classpath:hello/mapper/* ~~~ ~~~ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <!-- 映射dao --> <mapper namespace="hello.dao.TreeDao"> <!-- 結果集類型 --> <resultMap id="tree" type="hello.pojo.Tree"> <!-- 映射字段 --> <result column="id" property="id" /> <result column="name" property="name" /> <!-- 嵌套第二張表 --> <collection property="child" ofType="hello.pojo.Tree" > <id column="id2" property="id" /> <result column="name2" property="name" /> <!-- 嵌套第三張表 --> <collection property="child" ofType="hello.pojo.Tree" > <id column="id3" property="id" /> <result column="name3" property="name" /> </collection> </collection> </resultMap> </mapper> ~~~ 這里只是配置一個嵌套映射，在dao方法中通過`@ResultMap("tree")`使用這個映射。 最終查詢結果會映射成一個Tree對象，通過spring mvc轉換為json結果如下， 在一些前端框架中，實現樹形菜單就是需要用這種結構的JSON數據賦值 ~~~ [ { "id": "1", "name": "一級樹", "child": [ { "id": "11", "name": "二級樹-1", "child": [ { "id": "112", "name": "三級樹-1", "child": null }, { "id": "113", "name": "三級樹-2", "child": null } ] } ] } ] ~~~ # 使用JAVA注解還是XML XML執行一條SQL語句，并不是一定比JAVA注解執行多條SQL性能更優 一條SQL：關聯的表越多，笛卡爾積越大，查詢結果的冗余數據也越多 多條SQL：只需單表查詢，如果做好索引查詢效率會非常高，查詢結果也沒有冗余 。 在現實中，如果使用其中一種方式的性能較低，則可以償試另一方式進行測試，同時還要考慮數據庫優化策略