踩坑引出Mybatis的缓存机制
作者：互联网
问题引出
今天在做数据库的增删改查的时候，突然发现删除的数据行，子啊select之后还是会存在
找了找百度
发现罪魁祸首就是Mybatis的缓存机制搞的事情
什么是Mybatis缓存机制
缓存是一般的ORM 框架都会提供的功能，目的就是提升查询的效率和减少数据库的压力。跟Hibernate 一样，MyBatis 也有一级缓存和二级缓存，并且预留了集成第三方缓存的接口。
mybatis的缓存机制分为两个等级
- 一级缓存
一级缓存也叫本地缓存，MyBatis 的一级缓存是在会话（SqlSession）层面进行缓存的。MyBatis
的一级缓存是默认开启的，不需要任何的配置。首先我们必须去弄清楚一个问题，在MyBatis
执行的流程里面，涉及到这么多的对象，那么缓存PerpetualCache
应该放在哪个对象里面去维护？如果要在同一个会话里面共享一级缓存，这个对象肯定是在SqlSession 里面创建的，作为SqlSession的一个属性。
每当我们使用MyBatis开启一次和数据库的会话，MyBatis会创建出一个SqlSession对象表示一次数据库会话。
一级缓存的生命周期有多长？
MyBatis在开启一个数据库会话时，会 创建一个新的SqlSession对象，SqlSession对象中会有一个新的Executor对象，Executor对象中持有一个新的PerpetualCache对象；当会话结束时，SqlSession对象及其内部的Executor对象还有PerpetualCache对象也一并释放掉。
如果SqlSession调用了close()方法，会释放掉一级缓存PerpetualCache对象，一级缓存将不可用；
如果SqlSession调用了clearCache()，会清空PerpetualCache对象中的数据，但是该对象仍可使用；
SqlSession中执行了任何一个update操作(update()、delete()、insert()) ，都会清空PerpetualCache对象的数据，但是该对象可以继续使用；
这里也说了，执行了任何一个update的操作都会清空PerpetualCache对象，但是在有多个会话或者分布式环境下，会存在脏数据的问题。如果要解决这个问题，就要用到二级缓存。
- 二级缓存
二级缓存是用来解决一级缓存不能跨会话共享的问题的，范围是namespace 级别的，可以被多个SqlSession 共享（只要是同一个接口里面的相同方法，都可以共享），生命周期和应用同步。如果你的MyBatis使用了二级缓存，并且你的Mapper和select语句也配置使用了二级缓存，那么在执行select查询的时候，MyBatis会先从二级缓存中取输入，其次才是一级缓存，即MyBatis查询数据的顺序是：二级缓存 —> 一级缓存 —> 数据库。
作为一个作用范围更广的缓存，它肯定是在SqlSession 的外层，否则不可能被多个SqlSession 共享。而一级缓存是在SqlSession 内部的，所以第一个问题，肯定是工作在一级缓存之前，也就是只有取不到二级缓存的情况下才到一个会话中去取一级缓存。第二个问题，二级缓存放在哪个对象中维护呢？ 要跨会话共享的话，SqlSession 本身和它里面的BaseExecutor 已经满足不了需求了，那我们应该在BaseExecutor 之外创建一个对象。
问题的解决
上面那堆乱七八糟的定义没看懂没关系，主要我也没怎么看懂
想要解决缓存造成的对表进行修改后下次查询查到脏数据的问题
可以在Mapper文件中对缓存刷新机制进行配置就行
我们可以到两个属性flushCache和useCache
当为select语句时：
flushCache默认为false，表示任何时候语句被调用，都不会去清空本地缓存和二级缓存。
useCache默认为true，表示会将本条语句的结果进行二级缓存。
当为insert、update、delete语句时：
flushCache默认为true，表示任何时候语句被调用，都会导致本地缓存和二级缓存被清空。
update 的时候如果 flushCache=“false”，则当你更新后，查询的数据数据还是老的数据。
最终解决方法
在mapper里面的select后面每次插叙你完毕后都进行缓存刷新同时不要二级缓存就好
Such as：
<select id="query_alluser" flushCache="true" useCache="false" resultType="com.dao.usern">
select * from user
</select>
完毕
标签：缓存,一级,引出,对象,二级缓存,MyBatis,SqlSession,Mybatis 来源： https://blog.csdn.net/AcStudio/article/details/110328317