爲了增加查詢的性能，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 基礎就不介紹了，推薦看這個實戰項目：
在上面的代碼中也看到了，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
更多文章推薦：
2.2,000+ 道 Java面試題及答案整理(2024最新版)
3.免費獲取 IDEA 激活碼的 7 種方式（2024最新版）
覺得不錯，別忘了隨手點贊+轉發哦！