What is query cache? Introduction to the usage of MyBatis query cache

Please indicate the source for reprinting:

As mentioned earlier: Spring+SpringMVC+MyBatis in-depth learning and construction (7)-MyBatis delayed loading

1. What is query cache

Mybatis provides query caching to reduce database pressure and improve database performance.

Mybatis provides first-level cache and second-level cache.

The first-level cache is a SqlSession-level cache. When operating the database, you need to construct a sqlSession object. There is a data structure (HashMap) in the object for storing cache data. The cache data areas (HashMap) between different sqlSession do not affect each other.

The second-level cache is a mapper-level cache. Multiple sqlSession operates the same Mapper's sql statement. Multiple sqlSession can share the second-level cache. The second-level cache is across sqlSession.

Why use caching?

If there is data in the cache, there is no need to obtain it from the database, which greatly improves system performance.

2. Level 1 Cache

2.1 Working Principle of Level 1 Cache

## The first time the query is initiated for user information with user ID 1 , first find out whether there is user information with id 1 in the cache. If not, query the user information from the database.

Get the user information and store the user information in the first-level cache.

If sqlSession performs a commit operation (performing insert, update, delete), clear the first-level cache in sqlSession. The purpose of this is to store the latest information in the cache and avoid dirty reads.

The second time it is sent to query the user information with user ID 1, first find out whether there is user information with ID 1 in the cache. If there is in the cache, get the user information directly from the cache.

2.2 First-level cache test

Mybatis supports first-level cache by default and does not need to be configured in the configuration file.

Follow the first-level cache principle steps above to test.

    @Testpublic void testCache1() throws Exception{
        SqlSession sqlSession=sqlSessionFactory.openSession();
        UserMapper userMapper=sqlSession.getMapper(UserMapper.class);//下边查询使用一个SqlSession//第一次发起请求，查询id为1的用户User user1=userMapper.findUserById(1);
        System.out.println(user1);        //如果sqlSession去执行commit操作（执行插入、更新、删除），清空sqlSession中的一级缓存，//这样做的目的是为了让缓存中存储的是最新的信息，避免脏读。//更新user1的信息user1.setUsername("测试用户22");
        userMapper.updateUser(user1);//执行commit操作去清空缓存        sqlSession.commit();        //第二次发起请求，查询id为1的用户User user2=userMapper.findUserById(1);
        System.out.println(user2);

        sqlSession.close();
    }

2.3 Level 1 Cache Application

The official development is to integrate mybatis and spring, and the transaction is controlled in the service.

A service method includes many Mapper method calls.

service{

//When execution starts, start the transaction and create the SqlSession object

//The first time the mapper method is called findUserById(1)

//Call the mapper method findUserById(1) for the second time to get data from the first-level cache

//The method ends and sqlSession is closed

}

If two service calls are executed to query the same user information, the first-level cache will not be used. Because the session method ends, sqlSession will be closed and the first-level cache will be cleared.

3. Second-level cache

3.1 Second-level cache principle

First enable the second-level cache of mybatis.

sqlSession1 queries the user information with user ID 1. After querying the user information, it regrets that the query data is stored in the secondary cache.

If sqlSession3 executes SQL under the same mapper and executes commit submission, the data in the second-level cache area under the mapper will be cleared.

sqlSession2 queries the user information with user ID 1, checks whether data exists in the cache, and if so, directly retrieves the data from the cache.

The difference between the second-level cache and the first-level cache: the scope of the second-level cache is larger, and multiple sqlSession can share a UserMapper's second-level cache area. UserMapper has a second-level cache area (divided by namespace), and other mappers also have their own second-level cache areas (divided by namespace).

Each namespace mapper has a second-level cache area. If the namespaces of two mappers are the same, the data obtained by the two mappers executing SQL queries will be stored in the same second-level cache area.

3.2 Turn on the second-level cache

Mybatis’s second-level cache is mapper scope level. In addition to setting the main switch of the second-level cache in SqlMapConfig.xml, it must also be turned on in the specific mapper.xml. Level 2 cache.

Add to the core configuration file SqlMapConfig.xml:

<setting name="cacheEnabled" value="true"/>

##cacheEnabledConfigure global on/off settings for all caches under this configuration file. true falsetrue

在UserMapper.xml中开启二级缓存，UserMapper.xml下的sql执行完成后存储在它的缓存区域（HashMap）。

3.3调用pojo类实现序列化接口

为了将缓存数据取出执行反序列划操作，因为二级缓存数据存储介质多种多样，不一定在内存。可能在硬盘、远程等。

3.4测试方法

    @Testpublic void testCache2() throws Exception{
        SqlSession sqlSession1=sqlSessionFactory.openSession();
        SqlSession sqlSession2=sqlSessionFactory.openSession();
        SqlSession sqlSession3=sqlSessionFactory.openSession();
        
        UserMapper userMapper1=sqlSession1.getMapper(UserMapper.class);
        UserMapper userMapper2=sqlSession2.getMapper(UserMapper.class);
        UserMapper userMapper3=sqlSession3.getMapper(UserMapper.class);        //第一次发起请求，查询id为1的用户User user1=userMapper1.findUserById(1);
        System.out.println(user1);//这里执行关闭操作，将sqlSession中的数据写到二级缓存区域        sqlSession1.close();        //使用sqlSession3执行commit()操作User user=userMapper3.findUserById(1);
        user1.setUsername("Joanna");
        userMapper3.updateUser(user);//执行提交，清空UserMapper下边的二级缓存        sqlSession3.commit();
        sqlSession3.close();        //第二次发起请求，查询id为1的用户User user2=userMapper2.findUserById(1);
        System.out.println(user2);
        sqlSession2.close();
    }

3.5禁用二级缓存

在statement中设置useCache=false可以禁用当前select语句的二级缓存，即每次查询都会发出sql，默认情况是true，即该sql使用二级缓存。

useCache="false">

3.6刷新缓存（就是清空缓存）

 在mapper的同一个namespace中，如果有其它insert、update、delete操作数据后需要刷新缓存，如果不执行刷新缓存会出现脏读。

设置statement配置中的flushCache="true"属性，默认情况下为true即刷新缓存，如果改成false则不会刷新。使用缓存时如果手动修改数据库表中的查询数据会出现脏读。

flushCache="true">

 总结：一般情况下执行完commit操作都需要刷新缓存，flushCache=true表示刷新缓存，这样可以避免数据库脏读。

3.7 Mybatis Cache参数

flushInterval（刷新间隔）可以被设置为任意的正整数，而且它们代表一个合理的毫秒形式的时间端。默认情况是不设置，也局势没有刷新间隔，缓存仅仅调用语句时刷新。

size（引用数目）可以被设置为任意正整数，要记住你缓存的对象数目和你运行环境的可用内存资源数目。默认值是1024。

readOnly（只读）属性可以被设置为true或false。只读的缓存会给所有调用者返回缓存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存会返回缓存对象的拷贝（通过序列化）。这会慢一些，但是安全，因此默认是false。

如下例子：

这个更高级的配置创建了一个 FIFO 缓存,并每隔 60 秒刷新,存数结果对象或列表的 512 个引用,而且返回的对象被认为是只读的,因此在不同线程中的调用者之间修改它们会导致冲突。可用的收回策略有, 默认的是 LRU:

1. LRU – 最近最少使用的:移除最长时间不被使用的对象。

2. FIFO – 先进先出:按对象进入缓存的顺序来移除它们。

3. SOFT – 软引用:移除基于垃圾回收器状态和软引用规则的对象。

4. WEAK – 弱引用:更积极地移除基于垃圾收集器状态和弱引用规则的对象。

4.mybatis整合ehcache

ehcache是一个纯Java的进程内缓存框架，是一种广泛使用的开源Java分布式缓存，具有快速、精干等特点，是Hibernate中默认的CacheProvider。

4.1分布式缓存

为了提高系统并发、性能，一般会系统进行分布式部署（集群部署方式）

 

 

 

不使用分布式缓存，缓存的数据在各个服务单独存储，不方便系统开发。所以要使用分布式缓存对缓存数据进行集中管理。

mybatis的特长是sql操作，缓存数据的管理不是mybatis的特长。mybatis无法实现分布式缓存，需要和其它分布式缓存框架进行整合，如：redis、memcached、ehcache等。

4.2整合方法（掌握）

mybatis提供了一个cache接口，如果要实现自己的缓存逻辑，实现cache接口开发即可。

mybatis和ehcache整合，mybatis和ehcache整合包中提供了一个cache接口的实现类。

mybatis默认的cache实现类是:

4.3加入ehcache包

4.4整合ehcache

配置mapper中cache中的type为ehcache对cache接口的实现类型。

4.5加入ehcache的配置文件

在classpath下配置ehcache.xml

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="../config/ehcache.xsd"><diskStore path="F:\develop\ehcache" /><defaultCache maxElementsInMemory="1000" 
        maxElementsOnDisk="10000000"eternal="false" 
        overflowToDisk="false" 
        timeToIdleSeconds="120"timeToLiveSeconds="120" 
        diskExpiryThreadIntervalSeconds="120"memoryStoreEvictionPolicy="LRU"></defaultCache></ehcache>

Attribute description:

diskStore: Specify the storage location of data on the disk.

defaultCache: When creating a Cache with CacheManager.add ("demoCache"), EhCache will adopt the management strategy specified by .

The following properties are required:

maxElementsInMemory: The maximum number of elements cached in memory.

maxElementsOnDisk: The maximum number of elements cached on disk, if 0 means infinity.

eternal: Set whether cached elements will never expire. If it is true, the cached data is always valid. If it is false, you have to judge it based on timeToIdleSeconds and timeToLiveSeconds.

overflowToDisk: Set whether to cache expired elements to disk when the memory cache overflows.

The following attributes are optional:

timeToIdleSeconds: When the time between two accesses to the data cached in EhCache exceeds the value of the timeToIdleSeconds attribute, the data will be deleted. Default value It is 0, which means the idle time is infinite.

timeToLiveSeconds: The effective lifetime of the cache element. The default is 0, which means the element survival time is infinite.

diskSpoolBufferSizeMB: This parameter sets the buffer size of DiskStore (disk cache). The default is 30MB, each Cache should have its own buffer.

diskPersistent: Whether to enable the disk to save data in EhCache when the VM is restarted. The default is false.

diskExpiryThreadIntervalSeconds - The disk cache cleanup thread running interval, the default is 120 seconds. Every 120s, the corresponding thread will clean the data in EhCache.

memoryStoreEvictionPolicy - When the memory cache reaches the maximum size and a new element is added, the policy of removing elements from the cache is used. The default is LRU (least recently used), the options are LFU (least frequently used) and FIFO (first in, first out).

4.6 Test program

Same as 3.4

4.7 Second-level cache application scenario

For query requests with many accesses and users do not have real-time requirements for query results High, at this time, mybatis second-level caching technology can be used to reduce database access and improve access speed. Business scenarios include: time-consuming statistical analysis SQL, telephone bill query SQL, etc.

The implementation method is as follows: by setting the refresh interval, mybatis automatically clears the cache at intervals, and sets the cache refresh interval flushInterval according to the frequency of data changes, such as setting it to 30 minutes, 60 minutes, 24 hours, etc., according to Depends on demand.

4.8 Second-level cache limitations

Mybatis second-level cache is not good at fine-grained data level caching, such as the following requirements: caching product information, due to the number of product information query visits Large, but users are required to query the latest product information every time. At this time, if you use mybatis's second-level cache, it will not be possible to refresh only the cached information of the product when a product changes and not refresh the information of other products, because mybatis's The second-level cache area is divided into mappers. When a product information changes, all cached data of all product information will be cleared. To solve such problems, the business layer needs to cache data in a targeted manner based on needs.

If this article is helpful to you, please tip me on WeChat~

	Description	Allowed values	Default value

The above is the detailed content of What is query cache? Introduction to the usage of MyBatis query cache. For more information, please follow other related articles on the PHP Chinese website!