寫一個緩存類，將數據寫到緩存中時把緩存時間設置為1年或者更久
然後當你資料庫更新後清除這個緩存或者將緩存時間改成0，這樣再次進入這個頁面的時候就會被新數據重新緩存進來了~
『貳』 如何清理mysql資料庫緩存數據
1、打開mysql的客戶端 這里使用navicat，連接資料庫，等到navicat主頁面，雙擊需要操作的資料庫連接。
『叄』 如何Android資料庫緩存進行管理
無論大型或小型應用，靈活的緩存可以說不僅大大減輕了伺服器的壓力，而且因為更快速的用戶體驗而方便了用戶。
Android的apk可以說是作為小型應用，其中99%的應用並不是需要實時更新的，而且詬病於蝸牛般的移動網速，與伺服器的數據交互是能少則少，這樣用戶體驗才更好，這也是我們有時舍棄webview而採用json傳輸數據的原因之一。
採用緩存，可以進一步大大緩解數據交互的壓力，特此，我們簡略列舉一下緩存管理的適用環境：
1. 提供網路服務的應用
2. 數據更新不需要實時更新，但是哪怕是3-5分鍾的延遲也是可以採用緩存機制。
3. 緩存的過期時間是可以接受的(不會因為緩存帶來的好處，導致某些數據因為更新不及時而影響產品的形象等)
帶來的好處：
1. 伺服器的壓力大大減小
2. 客戶端的響應速度大大變快(用戶體驗)
3. 客戶端的數據載入出錯情況大大較少，大大提高了應有的穩定性(用戶體驗)
4. 一定程度上可以支持離線瀏覽(或者說為離線瀏覽提供了技術支持)
一、緩存管理的方法
這里的緩存管理的原理很簡：通過時間的設置來判斷是否讀取緩存還是重新下載。
裡面會有一些細節的處理，後面會詳細闡述。
基於這個原理，目前鄙人見過的兩種比較常見的緩存管理方法是:資料庫法和文件法。
二、資料庫法緩存管理
這種方法是在下載完數據文件後，把文件的相關信息如url，路經，下載時間，過期時間等存放到資料庫，下次下載的時候根據url先從資料庫中查詢，如果查詢到當前時間並未過期，就根據路徑讀取本地文件，從而實現緩存的效果。
從實現上我們可以看到這種方法可以靈活存放文件的屬性，進而提供了很大的擴展性，可以為其它的功能提供一定的支持；
從操作上需要創建資料庫，每次查詢資料庫，如果過期還需要更新資料庫，清理緩存的時候還需要刪除資料庫數據，稍顯麻煩，而資料庫操作不當又容易出現一系列的性能，ANR問題，實現的時候要謹慎，具體作的話，但也只是增加一個工具類或方法的事情。
還有一個問題，緩存的資料庫是存放在/data/data/<package>/databases/目錄下，是佔用內存空間的，如果緩存累計，容易浪費內存，需要及時清理緩存。
當然這種方法從目前一些應用的實用上看，我沒有發現什麼問題。
本文我側重強調第二種方法，第一種方法的實現，就此掠過。
三、文件法緩存管理
這種方法，使用File.lastModified()方法得到文件的最後修改時間，與當前時間判斷是否過期，從而實現緩存效果。
實現上只能使用這一個屬性，沒有為其它的功能提供技術支持的可能。
操作上倒是簡單，比較時間即可。本身處理也不容易帶來其它問題，代價低廉。
四、文件法緩存管理的兩點說明
1. 不同類型的文件的緩存時間不一樣。
籠統的說，不變文件的緩存時間是永久，變化文件的緩存時間是最大忍受不變時間。
說白點，圖片文件內容是不變的，直到清理，我們是可以永遠讀取緩存的。
配置文件內容是可能更新的，需要設置一個可接受的緩存時間。
2. 不同環境下的緩存時間標准不一樣。
無網路環境下，我們只能讀取緩存文件，哪怕緩存早就過期。
wifi網路環境下，緩存時間可以設置短一點，一是網速較快，而是流量不要錢。
移動數據流量環境下，緩存時間可以設置長一點，節省流量，就是節省金錢，而且用戶體驗也更好。
舉個例子吧，最近本人在做的一個應用在wifi環境下的緩存時間設置為5分鍾，移動數據流量下的緩存時間設置為1小時。
這個時間根據自己的實際情況來設置：數據的更新頻率，數據的重要性等。
五、何時刷新
開發者一方面希望盡量讀取緩存，用戶一方面希望實時刷新，但是成都網站製作響應速度越快越好，流量消耗越少越好，是一個矛盾。
其實何時刷新我也不知道，這里我提供兩點建議：
1. 數據的最長多長時間不變，對應用無大的影響。
比如，你的數據更新時間為1天，則緩存時間設置為4~8小時比較合適，一天他總會看到更新，如果你覺得你是資訊類應用，再減少，2~4小時，如果你覺得數據比較重要或者比較受歡迎，用戶會經常把玩，再減少，1~2小時，依次類推。
為了保險起見，你可能需要毫無理由的再次縮減一下。
2. 提供刷新按鈕。
上面說的保險起見不一定保險，最保險的方法使在相關界面提供一個刷新按鈕，為緩存，為載入失敗提供一次重新來過的機會，有了這個刷新按鈕，我們的心也才真的放下來。
『肆』 Oracle資料庫緩存大小怎麼設置，比如要設置一個緩存為8G的。這個數值是怎麼計算的
10g之前可以設置db_cache_size 來指定緩存大小
10g開始可以使用sga_target（當然你也可以不用，但是推薦用），來設定整個共享內存區域大小，包括緩存和共享池等。不需要再單獨設置db cache
11g可以設置memory_target，不光包括了sga，還包括了pga,是所有給oracle的內存的總和，就更方便了。
如果你使用了sga_target或者memory_target，還同時設置了db_cache_size的話，那麼你設置的db_cache_size成為了緩存的最小值。
需要分配給資料庫多大內存取決於你的業務需要，你可以通過db cache advisor的視圖，來估計是否需要更大的緩存。
『伍』 如何更修改線上資料庫
待那個隊列對應的工作線程完成了上一個操作的資料庫的修改之後，才會去執行下一個操作，也就是緩存更新的操作，此時會從資料庫中讀取最新的值，然後寫入緩存中。
----僅供參考
『陸』 怎樣更改SP的默認緩存
進入 瀏覽器緩存當前訪問的JSP動態頁面 進行更改即可。
緩存的思想可以應用在軟體分層的各個層面。它是一種內部機制，對外界而言，是不可感知的。 資料庫本身有緩存，持久層也可以緩存。（比如：hibernate，還分1級和2級緩存） 業務層也可以有緩存（但一般來說，這是一個過程域，不會設緩存）。 表現層/數據服務層（傳統web的表現層）也可以設置緩存（jsp cache 就是這一層，實現在appserver上的緩存機制） 另外Browser也有緩存（如IE）這個大家也都知道（實現在 web server 上的緩存機制）。越上層的緩存效果越好，越底層的緩存影響越深遠。
『柒』 如何對資料庫進行預處理及資料庫緩存處理
修改環境變數，右擊「我的電腦」，選擇「高級」，點擊「環境變數」按鈕，修改temp和tmp路徑即可，用戶變數和系統變數都要改。
『捌』 如何修改db2資料庫日誌緩沖區大小設置
，可以使用下面的命令來更改該參數的值：
db2 -v update database cfg for DB_NAME using LOGBUFSZ 256 db2 -v terminate
2. 調優步驟
通過查看下面代碼中所示各行，使用資料庫快照來確定 LOGBUFSZ參數的值是否為最佳值：
Log pages read = 0 Log pages written = 12644
對於OLTP，一開始以至少256頁為佳；對於OLAP，則以 128 頁為佳。如果常常看到"Log pages read"大於0，那麼可能需要增加這個值。如果發生了回滾，也可能要讀取日誌頁。一般而言，"log pages read"和"log pages written"之比應當盡可能小。理想情況下，"log pages read"的值應為0，而"log pages written"的值應很大。當 log pages read 太多時，意味著需要一個較大的LOGBUFSZ。
『玖』 如何設置資料庫緩存
內存資料庫有現成的redis，高效存取鍵值對，鍵設為你的查詢條件，值設為你的查詢結果轉為字元串
查詢時先從redis取，沒有再查資料庫，並且設置redis的過期時間，這種方式需要項目對實時性要求不高，這樣你才能用緩存，而且如果你的項目沒有明顯的熱點，即沒有某些內容確定會多次被查到，那你緩存就不會命中，添加緩存反而影響你得速度
redis是一種nosql的內存資料庫，感興趣你可以了解一下，優點就是性能強勁
數據查詢請求多就把結果緩存下來，你查資料庫再快也沒有直接把結果從內存讀出來快
同樣的sql請求只有第一次查資料庫，之後通通讀內存
或者你乾脆藉助這種思想，創建一個全局的map對象，然後查詢條件作key
，結果作value，就省去了了解redis的過程，把整個資料庫裝內存不太科學，你有多少條數據啊