情況描述：

    有以下幾張表，單據表（t_bill）、貨物表（t_cargo）、原料表（t_raw_material）、配置表（t_configure），表關係如下：

一張單據對應多個貨物資訊，每種貨物都有自己對應的原料資訊，貨物和原料都有屬於自己的配置資訊。

需求如下：

當我查詢一個單據資訊的時候，會展示該單據下的所有貨物資訊，以及貨物所屬原料名稱和配置資訊，不是單純的物件，是需要通過DTO轉換的資料，意思就是說，貨物資訊、原料資訊、配置資訊需要組裝成為一個DTO。

按照常理來說，直接查詢單據就可以級聯查詢出單據明細資訊，這樣做也無可厚非，但是忽略了一點，如果一張單據裡面包含了成千上萬的貨物資訊，成千上萬的貨物又對應的成千上萬的原料，同時也對應了成千上萬的配置資訊，這個時候就會遇到資料量太大，導致前端請求超時問題。

最開始的解決方案：

用redis快取貨物和原料對應的配置資訊，這樣在查詢貨物和原料對應的配置資訊時，可以先從redis中查詢，如果有直接返回，如果沒有則再去資料庫查詢，這樣可以減少資料庫的開銷，提高查詢速度，在一定程度上看減少前端超時的問題，但是隨之而來又會有新的問題，那就是貨物和原料對應的配置資訊更新不及時的問題，意思就是說會存在髒資料問題，所以想到這些後續還需要更改更多程式碼，於是過段暫時放棄這種方式。

第二種解決方案：

在查詢明細資訊的時候，在程式碼中用HashMap的方式暫存資料，形式和redis相同，以key和value的形式在記憶體中儲存資料，因為貨物和原料中都是儲存的配置資訊的code，根據code拿到name，返回給前端，所以查詢的時候，先會去map中找，如果存在，則直接返回name，如果不存在，再去資料庫中查詢，然後add進map中，這樣在後續的查詢中，效率會更高，當然這帶來不利的因素就是記憶體會被增加，所以這個只是暫時的解決方案。

我寫這篇文章的目的在於想告訴大家，記憶體的效能大於Redis快取，Redis快取效能大於資料庫直接查詢。