資料庫的緩存機制
MySQL緩存機制簡單的說就是緩存sql文本及查詢結果，如果運行相同的sql，伺服器直接從緩存中取到結果，而不需要再去解析和執行sql。如果表更改 了，那麼使用這個表的所有緩沖查詢將不再有效，查詢緩存值的相關條目被清空。更改指的是表中任何數據或是結構的改變，包括INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改變了的表的使用MERGE表的查詢。顯然，這對於頻繁更新的表，查詢緩存是不適合的，而對於一些不常改變數據且有 大量相同sql查詢的表，查詢緩存會節約很大的性能。
命中條件
緩存存在一個hash表中,通過查詢SQL,查詢資料庫,客戶端協議等作為key.在判斷是否命中前,MySQL不會解析SQL,而是直接使用SQL去查詢緩存,SQL任何字元上的不同,如空格,注釋,都會導致緩存不命中.
如果查詢中有不確定數據,例如CURRENT_DATE()和NOW()函數,那麼查詢完畢後則不會被緩存.所以,包含不確定數據的查詢是肯定不會找到可用緩存的
工作流程
1. 伺服器接收SQL,以SQL和一些其他條件為key查找緩存表(額外性能消耗)
2. 如果找到了緩存,則直接返回緩存(性能提升)
3. 如果沒有找到緩存,則執行SQL查詢,包括原來的SQL解析,優化等.
4. 執行完SQL查詢結果以後,將SQL查詢結果存入緩存表(額外性能消耗)
緩存失效
當某個表正在寫入數據,則這個表的緩存(命中檢查,緩存寫入等)將會處於失效狀態.在Innodb中,如果某個事務修改了表,則這個表的緩存在事務提交前都會處於失效狀態,在這個事務提交前,這個表的相關查詢都無法被緩存.
緩存的內存管理
緩存會在內存中開辟一塊內存(query_cache_size)來維護緩存數據,其中有大概40K的空間是用來維護緩存的元數據的,例如空間內存,數據表和查詢結果的映射,SQL和查詢結果的映射等.
MySQL將這個大內存塊分為小的內存塊(query_cache_min_res_unit),每個小塊中存儲自身的類型,大小和查詢結果數據,還有指向前後內存塊的指針.
MySQL需要設置單個小存儲塊的大小,在SQL查詢開始(還未得到結果)時就去申請一塊空間,所以即使你的緩存數據沒有達到這個大小,也需要用這個大小的數據塊去存(這點跟Linux文件系統的Block一樣).如果結果超出這個內存塊的大小,則需要再去申請一個內存塊.當查詢完成發現申請的內存塊有富餘,則會將富餘的空間釋放掉,這就會造成內存碎片問題,見下圖
此處查詢1和查詢2之間的空白部分就是內存碎片,這部分空閑內存是有查詢1查詢完以後釋放的,假設這個空間大小小於MySQL設定的內存塊大小,則無法再被使用,造成碎片問題
在查詢開始時申請分配內存Block需要鎖住整個空閑內存區,所以分配內存塊是非常消耗資源的.注意這里所說的分配內存是在MySQL初始化時就開辟的那塊內存上分配的.
緩存的使用時機
衡量打開緩存是否對系統有性能提升是一個很難的話題
1. 通過緩存命中率判斷, 緩存命中率 = 緩存命中次數 (Qcache_hits) / 查詢次數 (Com_select)
2. 通過緩存寫入率, 寫入率 = 緩存寫入次數 (Qcache_inserts) / 查詢次數 (Qcache_inserts)
3. 通過 命中-寫入率 判斷, 比率 = 命中次數 (Qcache_hits) / 寫入次數 (Qcache_inserts), 高性能MySQL中稱之為比較能反映性能提升的指數,一般來說達到3:1則算是查詢緩存有效,而最好能夠達到10:1
緩存配置參數
1. query_cache_type: 是否打開緩存
可選項
1) OFF: 關閉
2) ON: 總是打開
3) DEMAND: 只有明確寫了SQL_CACHE的查詢才會吸入緩存
2. query_cache_size: 緩存使用的總內存空間大小,單位是位元組,這個值必須是1024的整數倍,否則MySQL實際分配可能跟這個數值不同(感覺這個應該跟文件系統的blcok大小有關)
3. query_cache_min_res_unit: 分配內存塊時的最小單位大小
4. query_cache_limit: MySQL能夠緩存的最大結果,如果超出,則增加 Qcache_not_cached的值,並刪除查詢結果
5. query_cache_wlock_invalidate: 如果某個數據表被鎖住,是否仍然從緩存中返回數據,默認是OFF,表示仍然可以返回
GLOBAL STAUS 中 關於 緩存的參數解釋:
Qcache_free_blocks: 緩存池中空閑塊的個數
Qcache_free_memory: 緩存中空閑內存量
Qcache_hits: 緩存命中次數
Qcache_inserts: 緩存寫入次數
Qcache_lowmen_prunes: 因內存不足刪除緩存次數
Qcache_not_cached: 查詢未被緩存次數,例如查詢結果超出緩存塊大小,查詢中包含可變函數等
Qcache_queries_in_cache: 當前緩存中緩存的SQL數量
Qcache_total_blocks: 緩存總block數
減少碎片策略
1. 選擇合適的block大小
2. 使用 FLUSH QUERY CACHE 命令整理碎片.這個命令在整理緩存期間,會導致其他連接無法使用查詢緩存
PS: 清空緩存的命令式 RESET QUERY CACHE
2. 資料庫的緩存機制和作用是什麼
防止誤操作帶來的數據損壞和丟失
3. 如何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. 提供刷新按鈕。
上面說的保險起見不一定保險，最保險的方法使在相關界面提供一個刷新按鈕，為緩存，為載入失敗提供一次重新來過的機會，有了這個刷新按鈕，我們的心也才真的放下來。
4. 資料庫緩存機制是什麼緩存是如何作用資料庫
我們都知道 MySQL 的 Table Cache 是表定義的緩存，江湖上流傳著各種對這個參數的調優方法。
table cache 的作用，就是節約讀取表結構文件的開銷。對於table cache 是否命中，其實table cache 是針對於線程的，每個線程有自己的緩存，只緩存本線程的表結構定義。不過我們發現，strace 中沒有關於表結構文件的 open 操作（只有 stat 操作，定位表結構文件是否存在），也就是說 table cache 不命中，不一定需要讀取表結構文件。這種感覺好像是：在不命中 table cache 時，命中了另外一個表結構緩存。
運維建議：
我們讀一下 MySQL 的文檔，關於 table_open_cache 的建議值公式：建議值 = 最大並發數 * join 語句涉及的表的最大個數。
通過實驗我們容易理解：table_cache 是針對於線程的，所以需要最大並發數個緩存。另外，一個語句 join 涉及的表，需要同時在緩存中存在。所以最小的緩存大小，等於語句 join 涉及的表的最大個數。將這兩個數相乘，就得到了 MySQL 的建議值公式。
5. mybatis的緩存機制是怎麼樣的
MyBatis將數據緩存設計成兩級結構，分為一級緩存、二級緩存：
一級緩存是Session會話級別的緩存，位於表示一次資料庫會話的SqlSession對象之中，又被稱之為本地緩存。一級緩存是MyBatis內部實現的一個特性，用戶不能配置，默認情況下自動支持的緩存，用戶沒有定製它的權利（不過這也不是絕對的，可以通過開發插件對它進行修改）；
二級緩存是Application應用級別的緩存，它的是生命周期很長，跟Application的聲明周期一樣，也就是說它的作用范圍是整個Application應用。
6. php 數據緩存
1、普遍緩存技術：
數據緩存：這里所說的數據緩存是指資料庫查詢PHP緩存機制，每次訪問頁面的時候,都會先檢測相應的緩存數據是否存在，如果不存在，就連接資料庫，得到數據，並把查詢結果序列化後保存到文件中，以後同樣的查詢結果就直接從緩存表或文件中獲得。
用的最廣的例子看Discuz的搜索功能，把結果ID緩存到一個表中，下次搜索相同關鍵字時先搜索緩存表。
舉個常用的方法，多表關聯的時候，把附表中的內容生成數組保存到主表的一個欄位中，需要的時候數組分解一下，這樣的好處是只讀一個表，壞處就是兩個數據同步會多不少步驟，資料庫永遠是瓶頸，用硬碟換速度，是這個的關鍵點。
2、 頁面緩存：
每次訪問頁面的時候，都會先檢測相應的緩存頁面文件是否存在，如果不存在，就連接資料庫，得到數據，顯示頁面並同時生成緩存頁面文件，這樣下次訪問的時候頁面文件就發揮作用了。(模板引擎和網上常見的一些PHP緩存機制類通常有此功能)
3、 時間觸發緩存：
檢查文件是否存在並且時間戳小於設置的過期時間,如果文件修改的時間戳比當前時間戳減去過期時間戳大，那麼就用緩存，否則更新緩存。
4、 內容觸發緩存：
當插入數據或更新數據時，強制更新PHP緩存機制。
5、 靜態緩存：
這里所說的靜態緩存是指靜態化，直接生成HTML或XML等文本文件，有更新的時候重生成一次，適合於不太變化的頁面，這就不說了。
以上內容是代碼級的解決方案，我直接CP別的框架，也懶得改，內容都差不多，很容易就做到，而且會幾種方式一起用，但下面的內容是伺服器端的緩存方案，非代碼級的，要有多方的合作才能做到
6、 內存緩存:
Memcached是高性能的，分布式的內存對象PHP緩存機制系統，用於在動態應用中減少資料庫負載，提升訪問速度。
7、 php的緩沖器：
有eaccelerator， apc， phpa，xcache，這個這個就不說了吧，搜索一堆一堆的，自己看啦，知道有這玩意就OK
8、 MYSQL緩存：
這也算非代碼級的，經典的資料庫就是用的這種方式，看下面的運行時間，0.09xxx之類的
9、 基於反向代理的Web緩存:
如Nginx，SQUID，mod_proxy(apache2以上又分為mod_proxy和mod_cache)
10、 DNS輪詢：
BIND是一款開放源碼的DNS伺服器軟體，這個要說起來就大了，自己搜索去，大家知道有這個東西就行了。
7. redis緩存原理
redis緩存原理是sql語句時key值，查詢結果resultSet是value，當同一個查詢語句訪問時（select * from t_proct），只要曾經查詢過，調用緩存直接返回resultSet，節省了資料庫讀取磁碟數據的時間。
redis的存儲分為內存存儲、磁碟存儲和log文件三部分，配置文件中有三個參數對其進行配置。
save seconds updates，save配置，指出在多長時間內，有多少次更新操作，就將數據同步到數據文件。這個可以多個條件配合，比如默認配置文件中的設置，就設置了三個條件。
appendonly yes/no ，appendonly配置，指出是否在每次更新操作後進行日誌記錄，如果不開啟，可能會在斷電時導致一段時間內的數據丟失。因為redis本身同步數據文件是按上面的save條件來同步的，所以有的數據會在一段時間內只存在於內存中。
(7)資料庫的緩存機制擴展閱讀
redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系資料庫起到很好的補充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。
Redis支持主從同步。數據可以從主伺服器向任意數量的從伺服器上同步，從伺服器可以是關聯其他從伺服器的主伺服器。這使得Redis可執行單層樹復制。
存檔可以有意無意的對數據進行寫操作。由於完全實現了發布/訂閱機制，使得從資料庫在任何地方同步樹時，可訂閱一個頻道並接收主伺服器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗餘很有幫助。
redis的官網地址，redis.io。（域名後綴io屬於國家域名，是british Indian Ocean territory，即英屬印度洋領地）