Detaillierte Erläuterung des MyBatis-Abfragecaches in Java

Die Verwendung des Abfragecaches dient hauptsächlich der Verbesserung der Abfragezugriffsgeschwindigkeit. In diesem Artikel wird hauptsächlich der MyBatis-Abfragecache vorgestellt. Freunde, die ihn benötigen, können sich auf die Verwendung des

Abfragecaches beziehen, hauptsächlich um die Abfragezugriffsgeschwindigkeit zu verbessern. Vereinfachen Sie den wiederholten Abfragevorgang des Benutzers für dieselben Daten, anstatt jedes Mal die Ergebnisdaten aus der Datenbankabfrage abzurufen, und verbessern Sie so die Zugriffsgeschwindigkeit.

Der Abfrage-Caching-Mechanismus von MyBatis kann je nach Umfang des Cache-Bereichs (Lebenszyklus) in zwei Typen unterteilt werden: Cache der ersten Ebene und Cache der zweiten Ebene

1. Abfrage-Cache der ersten Ebene

Der MyBatis-Cache der ersten Ebene ist ein lokaler HashMap-Cache, der auf dem org.apache.ibatis.cache.impl.PerpetualCache basiert Klasse und ihr Gültigkeitsbereich ist Sqlsession. Führen Sie dieselbe SQL-Anweisung zweimal in derselben SQL-Sitzung aus. Nach der ersten Ausführung werden die Abfrageergebnisse in den Cache geschrieben. Beim zweiten Mal werden die Daten direkt aus dem Cache abgerufen, ohne die Datenbank abzufragen, wodurch die Abfrageeffizienz verbessert wird.

Wenn eine SQL-Sitzung endet, ist der Cache der ersten Ebene in der SQL-Sitzung nicht mehr vorhanden. Der First-Level-Cache von MyBatis ist standardmäßig aktiviert und kann nicht deaktiviert werden.

1. Nachweis der Existenz des First-Level-Cache

Testklasse:

//证明一级缓存的存在
@Test
public void test01(){
 //第一次查询
 Student student = dao.selectStudentById(2);
 System.out.println(student);
 //第二次查询
 Student student2 = dao.selectStudentById(2);
 System.out.println(student2);  
}

Mapper :

<mapper namespace="com.hcx.dao.IStudentDao">  
  <select id=selectStudentById resultType="com.hcx.beans.Student">
   select * from student where id=#{id}
  </select>
</mapper>

Konsole:

Nach der Ausführung wurde festgestellt, dass nur eine Abfrage aus der Datenbank ausgeführt wurde und das zweite Ergebnis direkt ausgegeben wurde von. Beachten Sie, dass beim zweiten Mal aus dem Sqlsession-Cache gelesen wird.

2. Die Grundlage für das Lesen von Daten aus dem Cache ist die SQL-ID

Der Cache der ersten Ebene speichert denselben SQL-Code Zuordnungs-ID Die Abfrageergebnisse und nicht die Abfrageergebnisse derselben SQL-Anweisung. Da der interne Abfragecache von MyBatis unabhängig davon, ob es sich um eine Abfrage der ersten oder zweiten Ebene handelt, die unterste Ebene mithilfe einer Hashmap implementiert wird: Der Schlüssel ist der id-bezogene Inhalt von SQL und der Wert ist das Ergebnis der Abfrage aus der Datenbank.

Mapper:

<mapper namespace="com.hcx.dao.IStudentDao">
  <select id=selectStudentById resultType="com.hcx.beans.Student">
   select * from student where id=#{id}
  </select>
  <select id="selectStudnetById2" resultType="com.hcx.beans.Student">
   select id,name,age,score,birthday from student where id=#{id}
  </select>
</mapper>

Dao-Schnittstelle:

public interface IStudentDao {  
 Student selectStudentById(int id);
 Student selectStudentById2(int id); 
}

Testklasse:

//证明从一级缓存中读取数据的依据:
//MyBatis：sql的id+sql语句
//hibernate：查询结果对象的id
@Test
public void test02(){
 Student student = dao.selectStudentById(2);
 System.out.println(student);

 Student student2 = dao.selectStudentById2(2);
 System.out.println(student2);  
}

Konsole:

Überprüfen Sie die Konsole und stellen Sie fest, dass die Ergebnisse der zweiten Abfrage genau mit denen der ersten übereinstimmen, die zweite Abfrage jedoch keine Daten aus dem Cache liest, sondern direkt aus der Datenbank. Dies liegt daran, dass die Grundlage für das Lesen von Daten aus dem Cache die Zuordnungs-ID der Abfrage-SQL und nicht das Abfrageergebnis ist.

3. Die Auswirkungen von Ergänzungen, Löschungen und Änderungen auf den Abfragecache der ersten Ebene

Ergänzungen, Löschungen und Änderungen, Unabhängig davon, ob Sqlsession.commit( ), den Abfragecache der ersten Ebene löscht, sodass die Abfrage erneut aus der Datenbank ausgewählt werden kann.

Testklasse:

@Test
public void test03(){
 Student student = dao.selectStudentById(2);
 System.out.println(student);
 //增删改操作都会清空一级缓存，无论是否提交
 dao.insertStudent(new Student("赵六",26,96.6));
 Student student2 = dao.selectStudentById(2);
 System.out.println(student2);  
}

Konsole:

2. Eingebaute Sekundärseite Level-Abfrage-Cache

Der Umfang des MyBatis-Abfrage-Cache ist entsprechend dem Namespace des Zuordnungsdatei-Mappers unterteilt. Die Mapper-Abfragedaten desselben Namespace werden im selben Cache-Bereich gespeichert. Daten in verschiedenen Namespaces stören sich nicht gegenseitig.

Sowohl der First-Level-Cache als auch der Second-Level-Cache werden je nach Namespace getrennt gespeichert. Der Unterschied zwischen dem Cache der ersten und der zweiten Ebene besteht jedoch darin, dass nach dem Schließen der SQL-Sitzung die Daten in der SQL-Sitzung nicht mehr vorhanden sind, dh der Cache der ersten Ebene ist nicht mehr vorhanden. Der Lebenszyklus des Second-Level-Cache wird mit der gesamten Anwendung synchronisiert, unabhängig davon, ob die SQL-Sitzung geschlossen ist.

Der Zweck der Verwendung des Second-Level-Cache besteht nicht darin, Daten zu teilen, da MyBatis Daten aus dem Cache basierend auf der SQL-ID und nicht auf dem abgefragten Objekt liest. Daher sind die Daten im Cache der zweiten Ebene nicht für die gemeinsame Nutzung mehrerer Abfragen vorgesehen (solange das Objekt in den Abfrageergebnissen aller Abfragen vorhanden ist, wird es direkt aus dem Cache gelesen. Dies ist die gemeinsame Nutzung von Daten. Das Der Cache im Ruhezustand dient der gemeinsamen Nutzung, MyBatis jedoch nicht), sondern dient dazu, die Speicherzeit der Abfrageergebnisse zu verlängern und die Systemleistung zu verbessern.

1. Cache-Nutzung der zweiten Ebene

Die Verwendung des Caches der zweiten Ebene erfordert nur zwei Schritte:

Serialisierte Entitäten

Hinzufügen der e20c50086bb6799ec27a6a73752fc01b-Tag in der Mapper-Zuordnungsdatei

1. Die Entitätsserialisierung

erfordert, dass die am Abfrageergebnis beteiligte Entitätsklasse java.io implementiert. Serialisierbare Schnittstelle. Wenn die Entitätsklasse eine übergeordnete Klasse oder Domänenattribute hat, müssen die übergeordnete Klasse und die Domänenattributklasse auch die Serialisierungsschnittstelle implementieren.

public class Student implements Serializable{
 private Integer id;
 private String name;
 private int age;
 private double score;
}

2. Fügen Sie das e20c50086bb6799ec27a6a73752fc01b-Tag in der Mapper-Zuordnungsdatei hinzu.

Fügen Sie das 707355b79f48ce957b037d12f8d8abdd-Tag hinzu Datei e20c50086bb6799ec27a6a73752fc01bSub-tag

<mapper namespace="com.hcx.dao.IStudentDao">
 <cache/>
  <select id=selectStudentById resultType="com.hcx.beans.Student">
   select * from student where id=#{id}
  </select>
</mapper>

3. Cache-Konfiguration der zweiten Ebene

Fügen Sie einige verwandte Attributeinstellungen zum 7fafc53ea28da12d39af9a5d7b76da1d对，即entry对象删除。

从DB中进行select查询的条件是：缓存中根本不存在这个key或者缓存中存在该key所对应的entry对象，但value为null。

设置增删改操作不刷新二级缓存：

若要使某个增、删或改操作不清空二级缓存，则需要在其2fe416ebc99307b5baa877beb4126ed0或f353c4e6f3e13c8cf4dcf649d0662b12或89f2e2a6c0b1bd54a34bdf16f85e8819中添加属性flushCache="false"，默认为true。

<insert id="insertStudent" flushCache="false">
  insert into student(name,age,score) values(#{name},#{age},#{score})
 </insert>

4.二级缓存的关闭

二级缓存默认为开启状态。若要将其关闭，则需要进行相关设置。
根据关闭的范围大小，可以分为全局关闭和局部关闭

1.全局关闭（在配置文件中设置）

全局关闭是指整个应用的二级缓存全部关闭，所有查询均不使用二级缓存。全局开关设置在主配置文件的全局设置c5c29794bda4e81a53ad53fcf163f82c中，该属性为cacheEnabled，设置为false，则关闭；设置为true，则开启，默认值为true。即二级缓存默认是开启的。

<!-- 关闭二级缓存 -->
<settings>
 <setting name="cacheEnabled" value="false"/>
</settings>

2.局部关闭（在映射文件的每个select中设置）

局部关闭指整个应用的二级缓存是开启的，但只是针对某个815c08aea17433a6272b681dc1d34168查询，不使用二级缓存。此时可以单独只关闭该815c08aea17433a6272b681dc1d34168标签的二级缓存。

在该要关闭二级缓存的815c08aea17433a6272b681dc1d34168标签中，将其属性useCache设置为false，即可关闭该查询的二级缓存。该属性默认为true，即每个815c08aea17433a6272b681dc1d34168查询的二级缓存默认是开启的。

<!--useCache="false"对当前sql的二级缓存的局部关闭 -->
 <select id=selectStudentById useCache="false" resultType="com.hcx.beans.Student">
  select * from student where id=#{id}
 </select>

5.二级缓存的使用原则

1.只能在一个命名空间下使用二级缓存

由于二级缓存中的数据是基于namespace的，即不同namespace中的数据互不干扰。在多个namespace中若均存在对同一个表的操作，那么这多个namespace中的数据可能就会出现不一致现象。

2.在单表上使用二级缓存

如果一个表与其它表有关联关系，那么久非常有可能存在多个namespace对同一数据的操作。而不同namespace中的数据互补干扰，所以就有可能出现多个namespace中的数据不一致现象。

3.查询多于修改时使用二级缓存

在查询操作远远多于增删改操作的情况下可以使用二级缓存。因为任何增删改操作都将刷新二级缓存，对二级缓存的频繁刷新将降低系统性能。

三、ehcache二级查询缓存

MyBatis允许使用第三方缓存产品。ehCache就是其中一种。

注意：使用ehcache二级缓存，实体类无需实现序列化接口。

1.导入jar包

2.添加ehcache.xml

解压ehcache的核心jar包ehcache-core-2.6.8.jar，将其中的一个配置文件ehcache-failsafe.xml直接放到项目的src目录下，并更名为ehcache.xml

(1)d72dee856555ebc5179da8bdfded1f5b标签

指定一个文件目录，当内存空间不够，需要将二级缓存中数据写到硬盘上时，会写到这个指定目录中。其值一般为java.io.tmpdir，表示当前系统的默认文件临时目录。

当前文件系统的默认文件临时目录，可以通过System.property()方法查看：

@Test
public void test(){
 String path = System.getProperty("java.io.tmpdir");
 System.out.println(path);
}

(2)730eca52cf3beed4d554a3843e167f2e标签

3.启用ehcache缓存机制

在映射文件的mapper中的e20c50086bb6799ec27a6a73752fc01b中通过type指定缓存机制为Ehcache缓存。默认为MyBatis内置的二级缓存org.apache.ibatis.cache.impl.PerpetualCache。

<mapper namespace="com.hcx.dao.IStudentDao">
 <cache type="org.mybatis.caches.ehcache.EhcacheCache"/>
  <select id=selectStudentById resultType="com.hcx.beans.Student">
   select * from student where id=#{id}
  </select>
</mapper>

4.ehcache在不同mapper中的个性化设置

在ehcache.xml中设置的属性值，会对该项目中所有使用ehcache缓存机制的缓存区域起作用。一个项目中可以有多个mapper，不同的mapper有不同的缓存区域。对于不同缓存区域也可进行专门针对于当前区域的个性设置，可通过指定不同mapper的62aecd17e676a41d3547c3bf97bb07b0属性值来设置。

62aecd17e676a41d3547c3bf97bb07b0属性值的优先级高于ehcache.xml中的属性值。

<mapper namespace="com.hcx.dao.IStudentDao">
 <cache type="org.mybatis.caches.ehcache.EhcacheCache"/>
   <property name="maxElementsInMemory" value="5000"/>
   <property name="timeToIdleSeconds" value="240"/>
 </cache>
</mapper>

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des MyBatis-Abfragecaches in Java. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!