mybatis二级缓存关键字
A. mybatis自带一级和二级缓存，为什么还要用redis
二级缓存是namespace区域内的，所以不同的namespace下操作同一张表，会导致数据不一致，个人从未使用过二级缓存，redis更灵活，功能更丰富
B. mybatis的cache-ref怎么使用
首先明确一点 cache-ref 只对二级缓存有效，没有使用二级缓存时，这东西没有意义。
以下说明只针对二级缓存。
当mybatis的当前命名空间存在DML的事务提交时，会使当前命名空间里的缓存失效，这样在查询时，会直接从数据库拿到数据，并再次缓存。但是如果是多表连接查询，如tableA join tableB，A表的DML操作在A的nameSpace,B表的DML操作在B的nameSpace，当B表在进行了数据修改时，不会使A表缓存失效，再使用tableA join tableB会直接从缓存中获取数据，因为此时缓存没有刷新，而且B表的数据也有变化，那么此时读取的就是脏数据。
此时就需要在B的nameSpace里使用<cache-ref namespace="A"/>，保证跟新B时，A的缓存也失效。再在A里面执行 tableA join tableB时，会重新从数据库里查询最新数据。
C. Spring boot + Mybatis plus + Redis实现二级缓存
1.1 通过application.yml配置redis的连接信息，springboot默认redis用的lecttuce客户端，如果想用jedis的话，只需要在pom.xml中引入redis的时候排除在lecttuce，然后再导入jedis的jar包就好了，
1.2 打开mybatis plus的二级缓存，为true的时候是开启的，false是关闭二级缓存
1.3 编写缓存类继承Cache类，实现Cache中的方法
1.4 早*.xml中加上<cache>标签，type写你所编写二级缓存类的路径
D. mybatis二级缓存原理
mybatis篇
一级缓存的作用域是sqlsession级别的，也就是说不同的Sqlsession是不会走一级缓存的，那么如果需要跨Sqlsession的缓存，就需要使用到二级缓存了。
二级缓存的话默认是关闭的，所以需要我们开启，开启的方式官网也有介绍,需要在mybatis-config.xml核心配置文件中开启二级缓存功能，并且我们mapper.xml中也需要加入<cache/>标签，二者缺一不可，后面我们看源码就能知道为啥这两个缺一不可。
先来看个例子
执行结果很意外，为什么二级缓存的功能都开启了，结果sql还是执行了2次，并没有走缓存，其实，二级缓存还有一个要注意的点那就是必须要提交事务二级缓存才会保存记录，因为已经是跨SqlSession共享缓存了，所以事务必须要提交，否则会读取到因混滚导致的错误数据。
有个地方需要注意，二级缓存的Sqlsession中的Executor实际上是CachingExecutor
我们知道getMapper最终的执行都会走到MapperProxy类中的invoker方法，具体就来分析这个类。
最后来到了重点的地方
CacheKey我们可以认为他就是每个方法对应的一个唯一标识符。
这里我们就可以看出为什么之前两者必须要配置，cacheEnable开启了才会用CachingExecutor包装一下BaseExecutor，而<cache/>标签只有配置了才会走缓存的逻辑
这里的tcm
到这，我们就差不多揭开了二级缓存的秘密，重要的还是<cache/>这个标签，因为它的存在就对应着每个mapper.xml中的一个具体Cache类，而这个类在每个mapper.xml中又是同一个，所以最终的值是放入了Cache类中，key为CacheKey，value就是sql执行的结果。
至于为什么需要事务提交才能命中二级缓存，我们看下put方法就知道
这里的putObject并没有真正的把值存入Cache中，而是存入了待提交的Map中，所以再来看下commit做了什么
具体看tcm.commit()
而这里可以看到此处会遍历所有的TransactionCache并执行commit方法
真相就出来了，会遍历待提交的Map然后把里面的值都存入Cache中，所以后面的查询就能直接从Cache中拿到值了。
总结
二级缓存先会把Sqlsession中的Executor包装成包装成CacheingExecutor,所有的sql都会经过这个类，而该类通过mapper.xml中配置的唯一<cache/>标签生成的Cache类存放每个方法执行的结果
E. jojo那里可以缓存
Mybatis的一个重要特性是缓存。它的缓存机制可以极大地提高应用程序的性能。Mybatis缓存的主要目的是减少数据库虚毁访问次数，从而提高应用程序的性能。Mybatis提供了两种缓存：一级缓存和二级缓存。一级缓存是Mybatis默认启用的缓存，它位于SqlSession级别，当SqlSession关闭时，一级缓存也会被清空。二级缓存是Mybatis可选择启用的缓存，它位于Mapper级别，可以被多个SqlSession共享，其中的数据会在多个SqlSession之间共享。Mybatis的缓存机制可以帮助减少数据库访问次数察盯，从而提高应败誉和用程序的性能。
F. MyBatis二级缓存带来的问题
MyBatis二级缓存使用的在某些场景下会出问题，来看一下为什么这么说。
假设我有一条select语句（开启了二级缓存）：
selecta.col1, a.col2, a.col3, b.col1, b.col2, b.col3fromtableA a, tableB bwherea.id= b.id;
对于tableA与tableB的操作定义在两个Mapper中，分别叫做MapperA与MapperB，即它们属于两个命名空间，如果此时启用缓存：
MapperA中执行上述sql语句查询这6个字段
tableB更新了col1与col2两个字段
MapperA再次执行上述sql语句查询这6个字段（前提是没有执行过任何insert、delete、update操作）
此时问题就来了，即使第（2）步tableB更新了col1与col2两个字段，第（3）步MapperA走二级缓存查询到的这6个字段依然是原来的这6个字段的值，因为我们从CacheKey的3组条件来看：
<select>标签所在的Mapper的Namespace+<select>标签的id属性
RowBounds的offset和limit属性，RowBounds是MyBatis用于处理分页的一个类，offset默认为0，limit默认为Integer.MAX_VALUE
<select>标签中定义的sql语句
对于MapperA来说，其中的任何一个条件都没有变化，自然会将原结果返回。
这个问题对于MyBatis的二级缓存来说是一个无解的问题，因此使用MyBatis二级缓存有一个前提： 必须保证所有的增删改查都在同一个命名空间下才行 。
G. mybatis 的二级缓存与延迟加载啥时候用
Hibernate与Mybatis对比总结【两者相同点】Hibernate与MyBatis都可以是通过SessionFactoryBuider由XML配置文件生成SessionFactory，然后由SessionFactory生成Session，最后由Session来开启执行事务和SQL语句。其中SessionFactoryBuider，SessionFactory，Session的生命周期都是差不多的。Hibernate和MyBatis都支持JDBC和JTA事务处理。【Mybatis优势】MyBatis可以进行更为细致的SQL优化，可以减少查询字段。MyBatis容易掌握，而Hibernate门槛较高。【Hibernate优势】Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。
H. mybatis打开二级缓存怎么配置
深入了解MyBatis二级缓存
一、创建Cache的完整过程
我们从SqlSessionFactoryBuilder解析mybatis-config.xml配置文件开始：
Reader reader = Resources.getResourceAsReader("mybatis-config.xml");
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(reader);
然后是：
XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
return build(parser.parse());
看parser.parse()方法：
parseConfiguration(parser.evalNode("/configuration"));
看处理Mapper.xml文件的位置：
mapperElement(root.evalNode("mappers"));
看处理Mapper.xml的XMLMapperBuilder：
XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration,
resource, configuration.getSqlFragments());
mapperParser.parse();
继续看parse方法：
configurationElement(parser.evalNode("/mapper"));
到这里：
String namespace = context.getStringAttribute("namespace");
if (namespace.equals("")) {
throw new BuilderException("Mapper's namespace cannot be empty");
}
builderAssistant.setCurrentNamespace(namespace);
cacheRefElement(context.evalNode("cache-ref"));
cacheElement(context.evalNode("cache"));
从这里看到namespace就是xml中<mapper>元素的属性。然后下面是先后处理的cache-ref和cache，后面的cache会覆盖前面的cache-ref，但是如果一开始cache-ref没有找到引用的cache，他就不会被覆盖，会一直到最后处理完成为止，最后如果存在cache，反而会被cache-ref覆盖。这里是不是看着有点晕、有点乱？所以千万别同时配置这两个，实际上也很少有人会这么做。
看看MyBatis如何处理<cache/>：
private void cacheElement(XNode context) throws Exception {
if (context != null) {
String type = context.getStringAttribute("type", "PERPETUAL");
Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
String eviction = context.getStringAttribute("eviction", "LRU");
Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
Long flushInterval = context.getLongAttribute("flushInterval");
Integer size = context.getIntAttribute("size");
boolean readWrite = !context.getBooleanAttribute("readOnly", false);
boolean blocking = context.getBooleanAttribute("blocking", false);
Properties props = context.getChildrenAsProperties();
builderAssistant.useNewCache(typeClass, evictionClass,
flushInterval, size, readWrite, blocking, props);
}
}
从源码可以看到MyBatis读取了那些属性，而且很容易可以到这些属性的默认值。
创建Java的cache对象方法为builderAssistant.useNewCache，我们看看这段代码：
public Cache useNewCache(Class<? extends Cache> typeClass,
Class<? extends Cache> evictionClass,
Long flushInterval,
Integer size,
boolean readWrite,
boolean blocking,
Properties props) {
typeClass = valueOrDefault(typeClass, PerpetualCache.class);
evictionClass = valueOrDefault(evictionClass, LruCache.class);
Cache cache = new CacheBuilder(currentNamespace)
.implementation(typeClass)
.addDecorator(evictionClass)
.clearInterval(flushInterval)
.size(size)
.readWrite(readWrite)
.blocking(blocking)
.properties(props)
.build();
configuration.addCache(cache);
currentCache = cache;
return cache;
}
从调用该方法的地方，我们可以看到并没有使用返回值cache，在后面的过程中创建MappedStatement的时候使用了currentCache。
二、使用Cache过程
在系统中，使用Cache的地方在CachingExecutor中：
@Override
public <E> List<E> query(
MappedStatement ms, Object parameterObject,
RowBounds rowBounds, ResultHandler resultHandler,
CacheKey key, BoundSql boundSql) throws SQLException {
Cache cache = ms.getCache();
获取cache后，先判断是否有二级缓存。
只有通过<cache/>,<cache-ref/>或@CacheNamespace,@CacheNamespaceRef标记使用缓存的Mapper.xml或Mapper接口（同一个namespace，不能同时使用）才会有二级缓存。
if (cache != null) {
如果cache存在，那么会根据sql配置(<insert>,<select>,<update>,<delete>的flushCache属性来确定是否清空缓存。
flushCacheIfRequired(ms);
然后根据xml配置的属性useCache来判断是否使用缓存(resultHandler一般使用的默认值，很少会null)。
if (ms.isUseCache() && resultHandler == null) {
确保方法没有Out类型的参数，mybatis不支持存储过程的缓存，所以如果是存储过程，这里就会报错。
ensureNoOutParams(ms, parameterObject, boundSql);
没有问题后，就会从cache中根据key来取值：
@SuppressWarnings("unchecked")
List<E> list = (List<E>) tcm.getObject(cache, key);
如果没有缓存，就会执行查询，并且将查询结果放到缓存中。
if (list == null) {
list = delegate.<E>query(ms, parameterObject,
rowBounds, resultHandler, key, boundSql);
tcm.putObject(cache, key, list); // issue #578 and #116
}
返回结果
return list;
}
}
没有缓存时，直接执行查询
return delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
在上面的代码中tcm.putObject(cache, key, list);这句代码是缓存了结果。但是实际上直到sqlsession关闭，MyBatis才以序列化的形式保存到了一个Map（默认的缓存配置）中。
三、Cache使用时的注意事项
1. 只能在【只有单表操作】的表上使用缓存
不只是要保证这个表在整个系统中只有单表操作，而且和该表有关的全部操作必须全部在一个namespace下。
2. 在可以保证查询远远大于insert,update,delete操作的情况下使用缓存
这一点不需要多说，所有人都应该清楚。记住，这一点需要保证在1的前提下才可以！
四、避免使用二级缓存
可能会有很多人不理解这里，二级缓存带来的好处远远比不上他所隐藏的危害。
缓存是以namespace为单位的，不同namespace下的操作互不影响。
insert,update,delete操作会清空所在namespace下的全部缓存。
通常使用MyBatis Generator生成的代码中，都是各个表独立的，每个表都有自己的namespace。
为什么避免使用二级缓存
在符合【Cache使用时的注意事项】的要求时，并没有什么危害。
其他情况就会有很多危害了。
针对一个表的某些操作不在他独立的namespace下进行。
例如在UserMapper.xml中有大多数针对user表的操作。但是在一个XXXMapper.xml中，还有针对user单表的操作。
这会导致user在两个命名空间下的数据不一致。如果在UserMapper.xml中做了刷新缓存的操作，在XXXMapper.xml中缓存仍然有效，如果有针对user的单表查询，使用缓存的结果可能会不正确。
更危险的情况是在XXXMapper.xml做了insert,update,delete操作时，会导致UserMapper.xml中的各种操作充满未知和风险。
有关这样单表的操作可能不常见。但是你也许想到了一种常见的情况。
多表操作一定不能使用缓存
为什么不能？
首先不管多表操作写到那个namespace下，都会存在某个表不在这个namespace下的情况。
例如两个表：role和user_role，如果我想查询出某个用户的全部角色role，就一定会涉及到多表的操作。
<select id="selectUserRoles" resultType="UserRoleVO">
select * from user_role a,role b where a.roleid = b.roleid and a.userid = #{userid}
</select>123123
像上面这个查询，你会写到那个xml中呢？？
不管是写到RoleMapper.xml还是UserRoleMapper.xml，或者是一个独立的XxxMapper.xml中。如果使用了二级缓存，都会导致上面这个查询结果可能不正确。
如果你正好修改了这个用户的角色，上面这个查询使用缓存的时候结果就是错的。
这点应该很容易理解。
在我看来，就以MyBatis目前的缓存方式来看是无解的。多表操作根本不能缓存。
如果你让他们都使用同一个namespace（通过<cache-ref>）来避免脏数据，那就失去了缓存的意义。
看到这里，实际上就是说，二级缓存不能用。整篇文章介绍这么多也没什么用了。
五、挽救二级缓存？
想更高效率的使用二级缓存是解决不了了。
但是解决多表操作避免脏数据还是有法解决的。解决思路就是通过拦截器判断执行的sql涉及到那些表（可以用jsqlparser解析），然后把相关表的缓存自动清空。但是这种方式对缓存的使用效率是很低的。
设计这样一个插件是相当复杂的，既然我没想着去实现，就不废话了。
最后还是建议，放弃二级缓存，在业务层使用可控制的缓存代替更好。
I. redis mybatis 二级缓存 为什么必须要有 <property name="connectionfactory" ref
1、mybatis的二级缓存的范围是命名空间（namespace）
2、只要这个命名空间下有一个 insert、update、delete mybatis 就会把这个命名空间下的二级缓清空。
3、如果同一个sql在不同的命名空间下，就会出现脏数据，因为一个insert、update、deleted 了另一个可能还使用者缓存数据，这样就会出现数据的不一致性。
4、如果更新、删除、插入的频率比较高的话，就会删除所有缓存在添加所有缓存在删除，这样缓存的命中率很低或者说根本就起不到缓存作用而且会消耗资源。
所以在没解决这个问题的前提下，还是不提倡使用二级缓存。