為了增加查詢的效能，MyBatis 提供了二級快取架構，分為一級快取和二級快取。
這兩級快取最大的區別就是：一級快取是會話級別的，只要出了這個 SqlSession，快取就沒用了。而二級快取可以跨會話，多個會話可以使用相同的快取！
一級快取使用簡單，預設就開啟。二級快取需要手動開啟，相對複雜，而且要注意的事項也多，否則可能有隱患。
一級快取
應用場景
訂單表與會員表是存在一對多的關係，為了儘可能減少 join 查詢，進行了分階段查詢。即先查詢出訂單表，再根據 member_id 欄位查詢出會員表，最後進行資料整合。而如果訂單表中存在重複的 member_id，就會出現很多重複查詢。
針對這種情況，MyBatis 透過一級快取來解決：在同一次查詢會話（SqlSession）中如果出現相同的語句及引數，就會從快取中取出，不再走資料庫查詢。
一級快取只能作用於查詢會話中，所以也叫做會話快取。
生效的條件
一級快取要生效，必須滿足以下條件條件：
- 必須是相同的會話
- 必須是同一個 mapper，即同一個 namespace
- 必須是相同的 statement，即同一個 mapper 中的同一個方法
- 必須是相同的 SQL 和引數
- 查詢語句中間沒有執行 session.clearCache() 方法
- 查詢語句中間沒有執行 insert/update/delete 方法（無論變動記錄是否與快取資料有無關係）
與 SpringBoot 整合時一級快取不生效原因
因為一級快取是會話級別的，要生效的話，必須要在同一個 SqlSession 中。但是與 SpringBoot 整合的 MyBatis，預設每次執行 SQL 語句時，都會建立一個新的 SqlSession！所以一級快取才沒有生效。
當呼叫 mapper 的方法時，最終會執行到 SqlSessionUtils 的 getSqlSession 方法，在這個方法中會嘗試在事務管理器中獲取 SqlSession，如果沒有開啟事務，那麼就會 new 一個 DefaultSqlSession。
所以說，即便在同一個方法中，透過同一個 mapper 連續呼叫兩次相同的查詢方法，也不會觸發一級快取。
解決與 SpringBoot 整合時一級快取不生效問題
Spring Boot 基礎就不介紹了，推薦看這個實戰專案：
https://github.com/javastacks/spring-boot-best-practice
在上面的程式碼中也看到了，MyBatis 在查詢時，會先從事務管理器中嘗試獲取 SqlSession，取不到才會去建立新的 SqlSession。所以可以猜測只要將方法開啟事務，那麼一級快取就會生效。
加上 @Transactional 註解，看下效果：
沒錯，的確生效了。在程式碼中可以看到，從事務管理器中，獲取到了 SqlSession：
再看看原始碼中是什麼時候將 SqlSession 設定到事務管理器中的。
SqlSessionUtils 中，在獲取到 SqlSession 後，會呼叫 registerSessionHolder 方法註冊 SessionHolder 到事務管理器：
具體是在 TransactionSynchronizationManager 的 bindResource 方法中操作的，將 SessionHolder 儲存到執行緒本地變數 (ThreadLocal) resources 中，這是每個執行緒獨享的：
然後在下次查詢時，就可以從這裡取出此 SqlSession，使用同一個 SqlSession 查詢，一級快取就生效了。
所以基本原理就是：如果當前執行緒存在事物，並且存在相關會話，就從 ThreadLocal 中取出。如果沒有事務，就重新建立一個 SqlSession 並儲存到 ThreadLocal 當中，共下次查詢使用。
至於快取查詢資料的地方，是在 BaseExecutor 中的 queryFromDatabase 方法中。執行 doQuery 從資料庫中查詢資料後，會立馬快取到 localCache(PerpetualCache型別) 中：
二級快取
應用場景
業務系統中存在很多的靜態資料如，字典表、選單表、許可權表等，這些資料的特性是不會輕易修改但又是查詢的熱點資料。
一級快取針對的是同一個會話當中相同 SQL，並不適合熱點資料的快取場景。
為了解決這個問題引入了二級快取，它脫離於會話之外，多個會話可以使用相同的快取。
看一個例子：
@RestController
@RequestMapping("item")
public class ItemController {
@Autowired
private ItemMapper itemMapper;
@GetMapping("/{id}")
public void getById(@PathVariable("id") Long id) {
System.out.println("==================== begin ====================");
Item item = itemMapper.selectById(id);
System.out.println(JSON.toJSONString(item));
}
}
當傳送兩次 get 請求時（兩個不同的會話），透過日誌可以發現第二次查詢使用的是快取。
開啟的方法
二級快取需要手動來開啟，MyBatis 預設沒有開啟二級快取。
1）在 yaml 中配置 cache-enabled 為 true
mybatis-plus:
configuration:
cache-enabled: true
2）Mapper 介面上新增 @CacheNamespace 註解
3）實體類實現 Serializable 介面
生效的條件
- 當會話提交或關閉之後才會填充二級快取
- 必須是同一個 mapper，即同一個名稱空間
- 必須是相同的 statement，即同一個 mapper 中的同一個方法
- 必須是相同的 SQL 語句和引數
- 如果 readWrite=true（預設就是true），實體對像必須實現 Serializable 介面
快取清除條件
- 只有修改會話提交之後，才會執行清空操作
- xml 中配置的 update 不能清空 @CacheNamespace 中的快取資料
- 任何一種增刪改操作都會清空整個 namespace 中的快取
原始碼中是如何填充二級快取的？
在生效條件中提到了，二級快取必須要在會話提交或關閉之後，才能生效！
在查詢到結果後，會呼叫 SqlSession 的 commit 方法進行提交（如果開啟事務的話，提交 SqlSession 走的不是這裡了，但最終填充二級快取的地方是一樣的）：
在此方法中，最終會呼叫到 TransactionalCache 的 flushPendingEntries 方法中填充二級快取：
SpringBoot 整合 MyBatis 的話，如果沒有開啟事務，每次執行查詢，都會建立新的 SqlSession，所以即使是在同一個方法中進行查詢操作，那也是跨會話的。
查詢時如何使用二級快取？
在查詢的時候，最終會呼叫 MybatisCachingExecutor 的 query 方法，裡面會從 TransactionalCacheManager 中嘗試根據 key 獲取二級快取的內容。
可以看到，這個 key 很長，由 mapper、呼叫的查詢方法、SQL 等資訊拼接而成，這也是為什麼想要二級快取生效，必須滿足前面所說的條件。
如果能在二級快取中查詢到，就直接返回了，不需要訪問資料庫。
具體的呼叫層數實在太多，用到了裝飾者模式，最終是在 PerpetualCache 中獲取快取的：
列印日誌是在 LoggingCache 中：
為什麼 MyBatis 預設不開啟二級快取？
答案就是，不推薦使用二級快取！
二級快取雖然能帶來一定的好處，但是有很大的隱藏危害！
它的快取是以 namespace(mapper) 為單位的，不同 namespace 下的操作互不影響。且 insert/update/delete 操作會清空所在 namespace 下的全部快取。
那麼問題就出來了，假設現在有 ItemMapper 以及 XxxMapper，在 XxxMapper 中做了表關聯查詢，且做了二級快取。此時在 ItemMapper 中將 item 資訊給刪了，由於不同 namespace 下的操作互不影響，XxxMapper 的二級快取不會變，那之後再次透過 XxxMapper 查詢的資料就不對了，非常危險。
來看一個例子：
@Mapper
@Repository
@CacheNamespace
public interface XxxMapper {
@Select("select i.id itemId,i.name itemName,p.amount,p.unit_price unitPrice " +
"from item i JOIN payment p on i.id = p.item_id where i.id = #{id}")
List<PaymentVO> getPaymentVO(Long id);
}
@Autowired
private XxxMapper xxxMapper;
@Test
void test() {
System.out.println("==================== 查詢PaymentVO ====================");
List<PaymentVO> voList = xxxMapper.getPaymentVO(1L);
System.out.println(JSON.toJSONString(voList.get(0)));
System.out.println("==================== 更新item表的name ==================== ");
Item item = itemMapper.selectById(1);
item.setName("java併發程式設計");
itemMapper.updateById(item);
System.out.println("==================== 重新查詢PaymentVO ==================== ");
List<PaymentVO> voList2 = xxxMapper.getPaymentVO(1L);
System.out.println(JSON.toJSONString(voList2.get(0)));
}
上面的程式碼，test() 方法中前後兩次呼叫了 xxxMapper.getPaymentVO 方法，因為沒有加 @Transactional 註解，所以前後兩次查詢，是兩個不同的會話，第一次查詢完後，SqlSession 會自動 commit，所以二級快取能夠生效；
然後在中間進行了 Item 表的更新操作，修改了下名稱；
由於 itemMapper 與 xxxMapper 不是同一個名稱空間，所以 itemMapper 執行的更新操作不會影響到 xxxMapper 的二級快取；
再次呼叫 xxxMapper.getPaymentVO，發現取出的值是走快取的，itemName 還是老的。但實際上 itemName 在上面已經被改了！
執行日誌如下：
所以說，二級快取的隱藏危害是比較大的，當有表關聯時，一個不注意就會出問題，不建議使用。
版權宣告：本文為CSDN博主「xujingyiss」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。原文連結：https://blog.csdn.net/xujingyiss/article/details/123481116
更多文章推薦：
1.Spring Boot 3.x 教程，太全了！
2.2,000+ 道 Java面試題及答案整理(2024最新版)
3.免費獲取 IDEA 啟用碼的 7 種方式（2024最新版）
覺得不錯，別忘了隨手點贊+轉發哦！