MyBatis 多表联合查询及优化

参考文章：https://blog.csdn.net/happylee6688/article/details/45967763

对于优化，我这里简单的提几点，大家可以考虑一下。

一. 首先
对表的设计，在设计表初期，不仅仅要考虑到数据库的规范性，还好考虑到所谓的业务，以及对性能的影响，比如，如果从规范性角度考虑的话，可能就会分多个表，但是如果从性能角度来考虑的话，庞大的数据量在多表联合查询的时候，相对于单表来说，就会慢很多，这时，如果字段不是很多的话，可以考虑冗余几个字段采用单表的设计。

二. 其次

就是在 sql 上下功夫了，对于联合查询，sql 的优化是很有必要的，到底是采用 INNER JOIN，还是采用 LEFT JOIN 亦或是 RIGHT JOIN 、OUTTER JOIN 等，都是要在满足业务需求之后，通过测试性能得出的结论。

三. 再次

就是在程序中调用的时候了，是采用懒加载，还是采用非懒加载的方式，这也算是一个因素吧，具体的还是要考虑业务的需要。

懒加载参考文章：https://blog.csdn.net/shfqbluestone/article/details/52888144

mybatis 的最主要的两个功能：
1.将 xml（或注解）和参数映射为 sql 交给 jdbc 去执行（增、删、改、查）

2.对于查询，将 jdbc 查询出的结果集映射为对象，将映射好的对象返回给用户。

懒加载的原理

mybatis 会循环处理结果集中返回的每行数据的，在处理之前首先会通过反射调用构造方法来创建 result 对象，结果集中的一行数据最终会映射为一个 result 对象（严格的来说是不对的，结果集中的一行数据在多表连接的情况下可能会映射为多个 result 对象，结果集中的一行数据在多表连接一对多的情况下结果集中的多行数据可能映射一个 result 对象，简单的单表查询结果集中的一行数据映射为一个 result 对象）。

其实在调用构造方法创建 result 对象的时候，构造方法还可能会有参数，需要先把结果集中的参数都提取出来，传给相应的构造方法通过反射创建对象。

mybatis 其实第一步是解析配置文件，把配置文件映射为 mybatis 的 Configuration 类，把配置文件的 xml 属性都映射为 Java 对象中的属性值。xml mapper 文件的处理比较复杂，< resultMap/> 标签映射为 ResultMap 对象， 标签中的< id/> 、< result/>、< association/> 等映射为 ResultMapping 对象。

其实要讲 mybatis 的实现过程，涉及到的点太多了，没法在一篇博客中讲。在这里，我只简单的讲一下原理。

接着再讲创建好 result 对象之后，mybatis 会循环 resultMappings（标签中的每个子标签都映射为一个 resultMapping，这些 resultMapping 组成了一个集合就是 resultMappings）集合，看有没有需要懒加载的属性，如果有的话，则会为这个 result 对象创建一个代理对象。

什么情况下才会出现需要懒加载的属性呢？只有 < association property=”author” column=”author_id” select=”selectAuthor” fetchType=”lazy”/> 
和 < collection property=”xxx” column=”xxx” select=”xxxx” fetchType=”lazy”/> 作为一个子标签出现在 < resultMap/> 标签（也不一定只是 < resultMap/> 标签，< collection/> 等标签事实上也算是一个 < resultMap/> 标签）之内才会出现需要懒加载的属性。select 属性和 fetchType=”lazy” 必须同时出现在 < collection/> 或 < association/> 属性中才需要懒加载，select 表示的是嵌套查询语句的 id ，fetchType=”lazy” 表示的是懒加载。

再接着讲 result 对象的代理对象，代理类是由 javassist 框架在运行时创建和加载的，这个代理类继承自 result 对象所属的类，以上面的例子为例，这个代理类继承自 Blog 类。

对于这个代理类的详细讲解在我的博客深入理解 Java 动态代理中有很详细的介绍，在这里我再简单的介绍下。

这个代理类继承了 result 对象所属的类（被代理类）并重写了被代理类的所有的方法，所以在代理对象上调用懒加载属性的 get 方法（getAuthor()）时会触发懒加载动作，mybatis 这时就能发现需要去懒加载一个属性，然后去加载这个属性。

其实，有几个方法都可以触发懒加载的操作，比如调用懒加载的 get/set 方法（确实调用 set 方法时也会触发懒加载操作）还有调用 clone()、equals()、hashCode()、toString()方法也会触发懒加载操作，如果代理对象有多个懒加载属性，则调用后面的这四个方法时会同时触发加载所有的懒加载属性。

懒加载操作只会触发一次，下次再调用这些方法时不会再次触发懒加载操作的。

懒加载其实又是一次查询操作，懒加载查询需要传递一些参数，还有一些其他条件。这些待传递的属性、参数、查询所需的 sql 语句等相关的条件都已经封装到了代理对象内部，这些条件封装在一个 Map 中，键是懒加载查询的属性名称，值是查询该属性所需的条件，包括参数、sql 语句等。懒加载完一个属性之后会把这个属性从 Map 中移除，所以再次出发懒加载操作时 mybatis 就知道该属性已经被被加载过了，不会重复加载。

再总结一下，懒加载功能使用了代理对象，所以在调用懒加载属性的 get/set 方法（或者是其他触发懒加载操作的方法）时 mybatis 才能知道这时候应该去加载懒加载属性。

四. 最后

就要用到数据库的缓存了，或者在数据库与程序的中间再加一层缓存。不过，还是建议用好数据库本身自带的缓存功能。

缓存参考文章: https://www.jianshu.com/p/c553169c5921

mybatis一级缓存：

1.Mybatis一级缓存的生命周期和SqlSession一致。
2.Mybatis的缓存是一个粗粒度的缓存，没有更新缓存和缓存过期的概念，同时只是使用了默认的hashmap，也没有做容量上的限定。
3.Mybatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，有操作数据库写的话，会引起脏数据，建议是把一级缓存的默认级别设定为Statement，即不使用一级缓存。

Mybatis二级缓存：

1.Mybatis的二级缓存相对于一级缓存来说，实现了SqlSession之间缓存数据的共享，同时粒度更加的细，能够到Mapper级别，通过Cache接口实现类不同的组合，对Cache的可控性也更强。
2.Mybatis在多表查询时，极大可能会出现脏数据，有设计上的缺陷，安全使用的条件比较苛刻。
3.在分布式环境下，由于默认的Mybatis Cache实现都是基于本地的，分布式环境下必然会出现读取到脏数据，需要使用集中式缓存将Mybatis的Cache接口实现，有一定的开发成本，不如直接用Redis，Memcache实现业务上的缓存就好了。

缓存总结

本文介绍了Mybatis的基础概念，Mybatis一二级缓存的使用及源码分析，并对于一二级缓存进行了一定程度上的总结。
最终的结论是Mybatis的缓存机制设计的不是很完善，在使用上容易引起脏数据问题，个人建议不要使用Mybatis缓存，在业务层面上使用其他机制实现需要的缓存功能，让Mybatis老老实实做它的ORM框架就好了哈哈。

缓存使用场景：读多写少