線上系統(tǒng)查詢一次要10s，我一怒優(yōu)化了幾百行的SQL

作者：石杉的架構筆記 2022-11-13 17:48:33

首先給大家引入一個場景，就是假設咱們寫的一套 Java 系統(tǒng)要跑一個幾百行的大 SQL 從 MySQL 里查詢數(shù)據(jù)，這個查詢是不是會速度非常的慢？

今天給大家來分享一個知識，那就是平時我們開發(fā)系統(tǒng)的時候，如何運用 Ehcache 這款本地緩存框架，把我們的查詢性能大幅度提升優(yōu)化，甚至讓很多查詢操作性能提升到 100 倍以上，下面就來講講這個話題。

業(yè)務場景

那肯定是了，這種幾百行大 SQL 往往都是那種超級復雜的查詢，可能涉及到了多表的關聯(lián)，也有的是那種數(shù)據(jù)指標的查詢，當然這種數(shù)據(jù)指標的查詢其實是會常見一些，就是針對各種數(shù)據(jù)表關聯(lián)起來查詢和統(tǒng)計一些指標。

一般來說的話，遇到這種超級大 SQL，往往會導致查詢 MySQL 性能很差，一般跑個 1s 甚至好幾秒那是很常見的了。

比如下圖：

所以往往對于這種場景來說，如果想要優(yōu)化一下這個查詢的性能，我們一般會用緩存。

也就是說，這一次用幾百行 SQL 語句查詢出了結果，好不容易用了幾秒鐘特別特別慢，接著其實就把這個結果緩存起來，下次請求過來，直接就用這個緩存里的數(shù)據(jù)拿出來返回就可以了，從緩存里讀結果以及返回，最多就是個 1ms 的事兒，根本不用幾秒那么漫長了。

如何通過緩存優(yōu)化查詢接口

那么問題來了，這個緩存的結果是放哪里？可能很多兄弟說可以放 Redis 里啊！但是，一定要每次用緩存就立馬上 Redis 嗎？

畢竟 Redis 還得額外部署集群，一旦引入 Redis，你還得考慮 Redis 是否會有故障，他的一些接入問題，以及跟 Redis 進行網(wǎng)絡通信畢竟也是要耗時的。

所以說，其實咱們優(yōu)先啊，可以先上本地緩存，也就是說，在業(yè)務系統(tǒng)運行的 JVM 的堆內存里，來緩存我們的查詢結果，下次請求來了，就從本地緩存里取出來直接返回就可以了。

如下圖：

基于大數(shù)據(jù)離線平臺進行緩存預熱

那么下一個問題又來了，很多查詢他可能當天第一次查的時候，本地緩存里是沒有的，還是得去 MySQL 里花費幾秒鐘來查詢，查完了以后才能放入到本地緩存里去，那這樣豈不是每天都有一些人第一次查詢很慢很慢嗎？

有沒有更好的辦法呢？當然有了，那就是緩存預熱，我們的業(yè)務系統(tǒng)可以把每天的查詢請求和參數(shù)都記錄下來。

對于一些數(shù)據(jù)報表的復雜查詢，其實每天的查詢條件都是差不多的，只不過是當天的日期會有變化而已，另外就是對于一些數(shù)據(jù)報表的數(shù)據(jù)，往往是通過大數(shù)據(jù)平臺進行離線計算的。

啥叫做離線計算呢？就是說可能有一個大數(shù)據(jù)系統(tǒng)每天凌晨的時候會把昨天的數(shù)據(jù)算一遍，算好的數(shù)據(jù)結果寫入到 MySQL 里去，然后每天更新數(shù)據(jù)就這一次，接著當天就不更新數(shù)據(jù)了。

如下圖：

然后呢，用戶每天都會對我們的系統(tǒng)發(fā)起很多次復雜報表查詢語句，但是這個 SQL 多表關聯(lián)的一些邏輯，以及附加的一些查詢條件幾乎都是有規(guī)律的是差不多的，就是每天選擇的當天日期是不太一樣的。

所以此時我們就可以把這些查詢條件記錄下來，然后每天凌晨的時候，趁著大家都睡覺了，就根據(jù)經常查詢的條件和當天日期，提前去查詢數(shù)據(jù)，查詢結果提前寫入本地緩存。

這樣用戶第一次來訪問，就可以直接從本地緩存里拿到最新的數(shù)據(jù)了，如下圖：

本地緩存框架：Ehcache

接著給大家講講咱們常用的本地緩存框架，Ehcache，這是大名鼎鼎的一個本地緩存框架，基本上 Ehcache 和 Guava 兩款本地緩存框架，用的是最多的，我們以 Ehcache 舉例來講講本地緩存框架是怎么用的。

首先得在咱們的項目 pom.xml 里引入對應的依賴，如下所示：

<dependency>
  <groupId>net.sf.ehcache</groupId>
  <artifactId>ehcache</artifactId>
  <version>2.10.2</version>
</dependency>

接著就可以引入一個 ehcache.xml 這種配置文件，對我們的緩存框架進行一定的配置了。

如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
    <cache name="report" 
         maxElementsInMemory="1000" 
         eternal="false" 
         timeToLiveSeconds="86400" 
         overflowToDisk="false" 
         disPersistent="false" 
         memoryStoreEvictionPolicy="LRU" />
</ehcache>

下面給大家解釋一下 ehcache 框架運行起來以后上述那些參數(shù)對他的影響，首先 maxElementsInMemory 說的就是他在內存里可以緩存多少條數(shù)據(jù)。

eternal 意思是說這個緩存是否是永久有效的，如果要是永久有效了那么 timeToLiveSeconds 也就沒用了。

但是如果不是永久有效的，就可以設置 timeToLiveSeconds 了，比如說可以設置緩存數(shù)據(jù)生存 24 小時，然后就自動過期，接著就必須要強制從數(shù)據(jù)庫里來查詢了。

overflowToDisk 是說如果緩存的數(shù)據(jù)要是超過了 maxElementsInMemory 的時候，是不是把多余的數(shù)據(jù)刷寫到磁盤里去。

diskPersistent 是說在 JVM 重啟的時候，要不要把內存里緩存的數(shù)據(jù)刷寫到磁盤里去，然后 JVM 重啟后再把磁盤里的數(shù)據(jù)恢復到內存里來，這倆參數(shù)，如果要是緩存的數(shù)據(jù)特別多的話，其實還是可以開啟的。

一方面是內存緩存不下了可以刷寫到磁盤去，一方面是內存里的數(shù)據(jù)重啟的時候還是持久化一下，然后重新加載到內存里來。

還有一個是 memoryStoreEvictionPolixy 是緩存的回收策略，因為如果要是緩存數(shù)據(jù)量過多了，導致內存和磁盤都放不下了，這個時候就必須回收掉一部分的數(shù)據(jù)了，一般都是用 LRU，最近最少使用策略來回收的。

下面是 Ehcache 在代碼里的使用示例：

public class EhcacheTest {
  public static void main(String[] args) {
    CacheManager cacheManager = CacheManager.create();
    Cache cache = cacheManager.getCache("report");
    cache.put(new Element("key", "value"));
    cache.get("key").getObjectValue();
  }

}

希望今天給大家分享的本地緩存知識可以幫助到大家以后遇到類似的復雜報表數(shù)據(jù)查詢場景的時候，可以利用這個知識點去優(yōu)化自己系統(tǒng)的性能！

責任編輯：姜華來源：今日頭條

Java SQL