相信很多关键词在运用ibatis2.x的兄弟并没有通过ibatis的xml映射文件来完成目标间的联系映射。本来也的确没有必要那么做，由于ibatis2.x采用的是“嵌套查询”的方法将目标之间的联系通过查询句子的直接拼装来完成，其作用和在DAO或Service中自行封装是相同的。 
不过这种方法存在“N+1查询疑问”。 
概括地讲，N+1查询疑问可所以这样导致的： 
? 你执行了一个独自的SQL句子来获取成果列表（即是+1）。 
? 对回来的每条记录，你执行了一个查询句子来为每个加载细节（即是N）。 
这个疑问会导致成百上千的SQL句子被执行。这一般不是希望的。 

而在Mybatis中，除了兼容ibatis2.x中的“嵌套查询”方法外，还供给了直接“嵌套成果”的方法，其作用相当于直接通过一句sql将查询出的dto目标自动封装成所需的目标。 
详细完成方法请自行参考Mybatis官方运用手册，不在此累述. 

不过实践上这一改善所带来的好处也是很有限的。由于这一方法在运用分页的时分并不起作用，或者说嵌套目标的成果集是不允许进行分页的。这一点在Mybatis结构中已经做出了清晰的约束（org.apache.ibatis.executor.resultset.NestedResultSetHandler里34行），而实践项目中需求分页的状况又格外多…… 
细心一想，一对多映射的确不能通过配置文件来分页，由于这时查询出的记录数并不等于实践回来目标的size，不过一对一映射为何也不允许就不太理解了。能够是由于一对一是一对多的特例，而在规划结构的时分并没有思考去处置或是难于处置这一特例吧。