Bitte geben Sie die Quelle für den Nachdruck an:
Wie bereits erwähnt: Spring+SpringMVC+MyBatis ausführliches Lernen und Aufbau (7) – MyBatis verzögertes Laden
mybatis bietet Abfrage-Caching, um den Datenbankdruck zu reduzieren und die Datenbankleistung zu verbessern.
mybatis bietet First-Level-Cache und Second-Level-Cache.
Der Cache der ersten Ebene ist der Cache der SqlSession-Ebene. Beim Betrieb der Datenbank müssen Sie ein sqlSession-Objekt erstellen. Das Objekt enthält eine Datenstruktur (HashMap) zum Speichern von Cache-Daten. Die Cache-Datenbereiche (HashMap) zwischen verschiedenen sqlSession beeinflussen sich gegenseitig nicht.
Der Cache der zweiten Ebene ist ein Cache auf Mapper-Ebene. Mehrere SQL-Anweisungen können den Cache der zweiten Ebene gemeinsam nutzen.
Warum Caching verwenden?
Wenn sich Daten im Cache befinden, müssen diese nicht aus der Datenbank abgerufen werden, was die Systemleistung erheblich verbessert.
Abfrage nach Benutzerinformationen mit Benutzer-ID 1 für starten Finden Sie beim ersten Mal heraus, ob Benutzerinformationen mit der ID 1 im Cache vorhanden sind. Wenn nicht, fragen Sie die Benutzerinformationen aus der Datenbank ab.
Benutzerinformationen abrufen und Benutzerinformationen im Cache der ersten Ebene speichern.
Wenn sqlSession einen Festschreibungsvorgang durchführt (Einfügen, Aktualisieren, Löschen), leeren Sie den Cache der ersten Ebene in sqlSession. Der Zweck besteht darin, die neuesten Informationen im Cache zu speichern und fehlerhafte Lesevorgänge zu vermeiden.
Wenn es zum zweiten Mal gesendet wird, um die Benutzerinformationen mit der Benutzer-ID 1 abzufragen, ermitteln Sie zunächst, ob sich Benutzerinformationen mit der ID 1 im Cache befinden, und rufen Sie die Benutzerinformationen direkt ab der Cache.
Mybatis unterstützt standardmäßig Level-1-Cache und muss nicht in der Konfigurationsdatei konfiguriert werden.
Befolgen Sie zum Testen die oben genannten Schritte zum Cache-Prinzip der ersten Ebene.
@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();
}wurde offiziell durch die Integration von Mybatis und Spring entwickelt und die Transaktionskontrolle ist in Betrieb.
Eine Servicemethode umfasst viele Mapper-Methodenaufrufe.
service{
// Beim Starten der Ausführung eine Transaktion starten und ein SqlSession-Objekt erstellen
// Die Mapper-Methode findUserById(1) zum ersten Mal aufrufen
// Rufen Sie die Mapper-Methode findUserById(1) zum zweiten Mal auf, um Daten aus dem Cache der ersten Ebene abzurufen
// Die Methode endet und sqlSession wird geschlossen
}
Wenn Sie zwei Dienstaufrufe ausführen, um dieselben Benutzerinformationen abzufragen, wird der Cache der ersten Ebene nicht verwendet. Da die Sitzungsmethode endet, wird die sqlSession geschlossen und die erste Ebene Der Cache wird geleert.
Aktivieren Sie zunächst den Second-Level-Cache von mybatis.
sqlSession1 fragt die Benutzerinformationen mit der Benutzer-ID 1 ab. Nach der Abfrage der Benutzerinformationen wird bedauert, dass die Abfragedaten im Cache der zweiten Ebene gespeichert werden.
Wenn sqlSession3 SQL unter demselben Mapper ausführt und die Commit-Übermittlung ausführt, werden die Daten im Cache-Bereich der zweiten Ebene unter dem Mapper gelöscht.
sqlSession2 fragt die Benutzerinformationen mit Benutzer-ID 1 ab, prüft, ob Daten im Cache vorhanden sind, und ruft die Daten in diesem Fall direkt aus dem Cache ab.
Der Unterschied zwischen dem Second-Level-Cache und dem First-Level-Cache: Der Umfang des Second-Level-Cache ist größer und mehrere sqlSession können den Second-Level-Cache-Bereich eines UserMappers gemeinsam nutzen. UserMapper verfügt über einen Cache-Bereich der zweiten Ebene (unterteilt durch Namespace), und andere Mapper verfügen ebenfalls über eigene Cache-Bereiche der zweiten Ebene (unterteilt durch Namespace).
Jeder Namespace-Mapper verfügt über einen Cache-Bereich der zweiten Ebene. Wenn die Namespaces zweier Mapper gleich sind, werden die von den beiden Mappern beim Ausführen von SQL-Abfragen erhaltenen Daten im selben Cache-Bereich der zweiten Ebene gespeichert.
Der Second-Level-Cache von Mybatis ist Mapper-Scope-Level. Zusätzlich zum Festlegen des Hauptschalters des Second-Level-Caches in SqlMapConfig.xml muss dies geschehen auch im spezifischen Mapper.xml Level 2-Cache aktiviert werden.
Fügen Sie in der Kernkonfigurationsdatei SqlMapConfig.xml Folgendes hinzu:
<setting name="cacheEnabled" value="true"/>
|
Beschreibung
|
Zulässige Werte |
Standardwert |
|||||||||
cacheEnabled |
Nehmen Sie globale Ein-/Aus-Einstellungen für alle Caches unter dieser Konfigurationsdatei vor. |
true false |
true |
在UserMapper.xml中开启二级缓存，UserMapper.xml下的sql执行完成后存储在它的缓存区域（HashMap）。
为了将缓存数据取出执行反序列划操作，因为二级缓存数据存储介质多种多样，不一定在内存。可能在硬盘、远程等。
@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();
}在statement中设置useCache=false可以禁用当前select语句的二级缓存，即每次查询都会发出sql，默认情况是true，即该sql使用二级缓存。
在mapper的同一个namespace中，如果有其它insert、update、delete操作数据后需要刷新缓存，如果不执行刷新缓存会出现脏读。
设置statement配置中的flushCache="true"属性，默认情况下为true即刷新缓存，如果改成false则不会刷新。使用缓存时如果手动修改数据库表中的查询数据会出现脏读。
总结：一般情况下执行完commit操作都需要刷新缓存，flushCache=true表示刷新缓存，这样可以避免数据库脏读。
flushInterval（刷新间隔）可以被设置为任意的正整数，而且它们代表一个合理的毫秒形式的时间端。默认情况是不设置，也局势没有刷新间隔，缓存仅仅调用语句时刷新。
size（引用数目）可以被设置为任意正整数，要记住你缓存的对象数目和你运行环境的可用内存资源数目。默认值是1024。
readOnly（只读）属性可以被设置为true或false。只读的缓存会给所有调用者返回缓存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存会返回缓存对象的拷贝（通过序列化）。这会慢一些，但是安全，因此默认是false。
如下例子：
这个更高级的配置创建了一个 FIFO 缓存,并每隔 60 秒刷新,存数结果对象或列表的 512 个引用,而且返回的对象被认为是只读的,因此在不同线程中的调用者之间修改它们会导致冲突。可用的收回策略有, 默认的是 LRU:
LRU – 最近最少使用的:移除最长时间不被使用的对象。
FIFO – 先进先出:按对象进入缓存的顺序来移除它们。
SOFT – 软引用:移除基于垃圾回收器状态和软引用规则的对象。
WEAK – 弱引用:更积极地移除基于垃圾收集器状态和弱引用规则的对象。
ehcache是一个纯Java的进程内缓存框架，是一种广泛使用的开源Java分布式缓存，具有快速、精干等特点，是Hibernate中默认的CacheProvider。
为了提高系统并发、性能，一般会系统进行分布式部署（集群部署方式）
不使用分布式缓存，缓存的数据在各个服务单独存储，不方便系统开发。所以要使用分布式缓存对缓存数据进行集中管理。
mybatis的特长是sql操作，缓存数据的管理不是mybatis的特长。mybatis无法实现分布式缓存，需要和其它分布式缓存框架进行整合，如：redis、memcached、ehcache等。
mybatis提供了一个cache接口，如果要实现自己的缓存逻辑，实现cache接口开发即可。
mybatis和ehcache整合，mybatis和ehcache整合包中提供了一个cache接口的实现类。
mybatis默认的cache实现类是:
配置mapper中cache中的type为ehcache对cache接口的实现类型。
在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>Attributbeschreibung:
diskStore: Geben Sie den Speicherort der Daten auf der Festplatte an.
defaultCache: Beim Erstellen eines Caches mit CacheManager.add („demoCache“) übernimmt EhCache die durch
Die folgenden Eigenschaften sind erforderlich:
maxElementsInMemory: Die maximale Anzahl der im Speicher zwischengespeicherten Elemente.
maxElementsOnDisk: Die maximale Anzahl der auf der Festplatte zwischengespeicherten Elemente, wenn 0 unendlich bedeutet.
ewig: Legen Sie fest, ob zwischengespeicherte Elemente niemals ablaufen. Wenn es wahr ist, sind die zwischengespeicherten Daten immer gültig. Wenn es falsch ist, müssen Sie es anhand von timeToIdleSeconds und timeToLiveSeconds beurteilen.
overflowToDisk: Legen Sie fest, ob abgelaufene Elemente auf der Festplatte zwischengespeichert werden sollen, wenn der Speichercache überläuft.
Die folgenden Attribute sind optional:
timeToIdleSeconds: Wenn die Zeit zwischen zwei Zugriffen auf die im EhCache zwischengespeicherten Daten den Wert des timeToIdleSeconds-Attributs überschreitet, werden die Daten gelöscht 0, was bedeutet, dass die Leerlaufzeit unendlich ist.
timeToLiveSeconds: Die effektive Lebensdauer des Cache-Elements. Der Standardwert ist 0, was bedeutet, dass die Überlebenszeit des Elements unendlich ist.
diskSpoolBufferSizeMB: Dieser Parameter legt die Puffergröße von DiskStore (Festplatten-Cache) fest. Der Standardwert ist 30 MB, jeder Cache sollte seinen eigenen Puffer haben.
diskPersistent: Ob die Festplatte aktiviert werden soll, um Daten im EhCache zu speichern, wenn die VM neu gestartet wird. Der Standardwert ist „false“.
diskExpiryThreadIntervalSeconds – Ausführungsintervall des Festplatten-Cache-Bereinigungsthreads, der Standardwert beträgt 120 Sekunden. Alle 120 Sekunden bereinigt der entsprechende Thread die Daten im EhCache.
memoryStoreEvictionPolicy – Wenn der Speichercache die maximale Größe erreicht und ein neues Element hinzugefügt wird, wird die Richtlinie zum Entfernen von Elementen aus dem Cache verwendet. Der Standardwert ist LRU (zuletzt verwendet), die Optionen sind LFU (zuletzt verwendet) und FIFO (First In, First Out).
Wie 3.4
Für Abfrageanfragen mit vielen Zugriffen und Benutzern ohne echte Der Zeitaufwand für die Abfrageergebnisse ist hoch. Derzeit kann die Second-Level-Caching-Technologie von Mybatis verwendet werden, um den Datenbankzugriff zu reduzieren und die Zugriffsgeschwindigkeit zu verbessern. Zu den Geschäftsszenarien gehören: zeitaufwändige statistische SQL-Analysen, SQL-Abfragen für Telefonrechnungen usw.
Die Implementierungsmethode lautet wie folgt: Durch Festlegen des Aktualisierungsintervalls löscht mybatis den Cache automatisch in regelmäßigen Abständen und legt das Cache-Aktualisierungsintervall „flushInterval“ entsprechend der Häufigkeit von Datenänderungen fest, z. B. auf 30 Minuten. 60 Minuten, 24 Stunden usw., je nach Bedarf.
Der Mybatis-Cache der zweiten Ebene eignet sich aufgrund der Anzahl der Produkte nicht für feinkörniges Caching auf Datenebene, wie z. B. die folgenden Anforderungen: Zwischenspeichern von Produktinformationen Informationsabfragebesuche Groß, aber Benutzer müssen jedes Mal die neuesten Produktinformationen abfragen. Wenn Sie den Second-Level-Cache von mybatis verwenden, ist es derzeit nicht möglich, nur die zwischengespeicherten Informationen des Produkts zu aktualisieren, wenn sich ein Produkt ändert Aktualisieren Sie die Informationen anderer Produkte nicht, da der Cache-Bereich der zweiten Ebene in Mapper unterteilt ist. Wenn sich eine Produktinformation ändert, werden alle zwischengespeicherten Daten aller Produktinformationen gelöscht. Um solche Probleme zu lösen, muss die Business-Schicht Daten gezielt und bedarfsgerecht zwischenspeichern.
Wenn dieser Artikel für Sie hilfreich ist, geben Sie mir bitte einen Tipp auf WeChat~
Das obige ist der detaillierte Inhalt vonWas ist ein Abfragecache? Einführung in die Verwendung des MyBatis-Abfragecaches. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
mybatis First-Level-Cache und Second-Level-Cache
Was ist der Unterschied zwischen Ibatis und Mybatis?
So konfigurieren Sie die Datenbankverbindung in mybatis
Was ist das Funktionsprinzip und der Prozess von Mybatis?
Was sind die Unterschiede zwischen Hibernate und Mybatis?
Welche Netzwerkdateiserver-Tools gibt es?
Einführung in den Standort des Win10-Bedienfelds
So registrieren Sie eine geschäftliche E-Mail-Adresse
