眾所周知，系統讀取資料時，從
記憶體中讀取要比從
硬碟上速度要快好幾百倍。故現在絕大部分應用系統，都會最大程度的使用快取(
記憶體中的乙個儲存區域)，來提高系統的執行效率。mysql資料庫也不例外。在這裡，筆者將結合自己的工作經驗，跟大家**一下，mysql資料庫中快取的管理技巧：如何合理配置mysql資料庫快取，提高快取命中率。
一、什麼時候應用系統會從快取中獲取資料?
資料庫從伺服器上讀取資料時，可以從硬碟的資料檔案中獲取資料，也可以從資料庫快取中讀取資料。現在資料庫管理員需要搞清楚的是，在什麼樣的情況下，系統是從快取中讀取資料，而不是從硬碟的資料檔案中讀取資料?
簡單的說，資料快取就是記憶體中的一塊儲存區域，其儲存了使用者的sql文字以及相關的查詢結果。通常情況下，使用者下次查詢時，如果所使用的sql文字是相同的，並且自從上次查詢後，相關的紀錄沒有被更新過，此時資料庫就直接採用快取中的內容。從這個原則中，可以看到如果要直接使用快取中的資料，至少要滿足以下幾個條件。
一是所採用的sql文字是相同的。當前後兩次使用者使用了相同的sql語句(假設不考慮其他條件)，則伺服器會從快取中讀取結果，而不需要再去解析和執行sql語句。這裡需要注意的是，這裡的sql文字必須一次不差的完全相同。如果前後兩次查詢，使用了不同的查詢條件。如第一次查詢時沒有輸入where條件語句。後來發現資料量過多，利用了where條件了過濾查詢的結果。此時即使最後的查詢結果是相同的，系統仍然是從資料檔案中獲取資料，而不是從資料快取中。再如，select後面所使用的欄位名稱也必須是相同的。如果有乙個欄位名稱不同或者前後兩次查詢所使用的字段數量不同，則系統都會認為是不同的sql語句，而重新解析並查詢。
二是從資料快取的角度考慮，大小寫是不敏感的。如前後兩次查詢時，採用的欄位名稱可能只有大小寫的差異。如第一次使用的是大小，第二次使用的是小寫，這系統認為仍然是相同的sql語句。或者說關鍵字大小寫等等這都是不敏感的。
三是要滿足二次查詢之間，資料記錄包括表結構都沒有被更改過。如果記錄所在的標更改了，如增加了乙個字段等等，此時使用這個表的所有緩衝資料系統將自動清空。這裡需要注意，這裡指的更改是乙個廣義的更改，包括表中任何資料或者結果的改變。舉乙個簡單的例子，第一次查詢時使用者需要查詢2023年的出貨資料。查詢後有使用者在這個表中插入了一條2023年1月份的出貨資訊。然後又有使用者需要查詢2023年的出貨資訊。使用的sql語句與第一次查詢時完全相同。在這種情況下，資料庫系統會使用快取中的資料嗎?答案是否定的。因為當中間使用者插入一條記錄時，系統會自動清空跟這個表相關的所有快取記錄。當第二次查詢時，快取中已經沒有這張表對應的快取資訊。此時就需要重新解析並查詢。
四是需要注意，預設字符集對快取命中率的影響。通常情況下，如果客戶端與伺服器之間所採用的預設字符集不同，則即使查詢語句相同、在兩次查詢之間記錄與表結構也沒有被更改，系統仍然認為是不同的查詢。對於這一點需要特別的注意，大家比較容易忽視。
二、提高快取命中率的建議。
從上面的條件分析中可以看出，利用快取中的資料具有比較嚴格的條件。其實這些條件也是合情合理的。主要是為了保障資料的一致性。對以上這些條件有深入的認識之後，現在資料庫管理員需要考慮的是，如何來提高這個快取的命中率?對此筆者有如下幾個建議。
一是在配置時，客戶端與伺服器端要使用相同的字符集。如果客戶端(或者說第三方工具)與伺服器端使用的字符集不同，那麼任何情況下都不會使用快取功能。特別在國內，需要用到中文的字符集。此時特別需要注意，客戶端預設字符集要與伺服器端的預設字符集相同。注意，這裡是相同，而不是相容。有時候即使採用了不同的字符集，客戶端上仍然可以正常顯示。這主要是因為有些字符集雖然不相同，但是是相互相容的。在快取管理上，需要相同，光相容還不行。
二是在客戶端上，要固化查詢的語句。如現在有財務人員和採購人員同時從系統中查詢11月份的出貨資料。顯然他們崗位職責不同，所需要欄位的內容是不同的。此時在客戶端出，可以允許使用者設定自己所需要的表單格式。但是筆者建議，後台所採用的sql語句最好是相同的。這裡資料會經過三個渠道：後台資料庫、客戶端、使用者。筆者的意識時，後台資料庫與客戶端之間的互動採用相同的sql語句。然後客戶端與使用者之間進行互動時，根據使用者定義的格式(包括字段前後的排列、不包括查詢條件語句的差異)向使用者顯示資料。此時由於採用了相同的sql語句(只是使用者對於顯示格式的要求不同)，從而可以提高應用系統的查詢效率。
三是提高記憶體中快取的配置，來提高命中率。一般在伺服器啟動時，作業系統會跟資料庫軟體協商快取空間的大小。當快取工作不足時，快取中最舊的快取記錄會被最新的訊息所覆蓋。可見，如果能夠提高快取空間，就可以提高命中率。這就好像打靶，目標多了，命中的機率也會高許多。不過使用者的併發數越多，這個設定的效果會越不明顯。
四是通過分割槽表可以提高快取的命中率。在上面的條件分析中，大家可以看到，只要所查詢的表中插入了一條記錄，系統就會清空快取記錄。現在以查詢出貨記錄為例。出貨記錄表每天都在更新，而使用者在年初時，會經常需要查詢上一年的出貨記錄。此時由於這個表中的資料每個小時都在更新，那麼快取中的資訊會不斷的被情況。此時快取的命中率顯然不會很高。針對這種情況，筆者建議可以採用分割槽表。如可以通過系統設定，將2023年的出貨記錄單獨存放在乙個出貨的分割槽表中。即每乙個年度都使用一張單獨的分割槽表。此時2023年的紀錄，就不會影響到2023年的分割槽表。此時如果使用者重複查詢2023年的出貨資訊，只要其使用的sql語句相同(沒有採用不同的查詢條件)，那麼就可以享受快取機制所帶來的效益，提高應用系統的查詢效果。。
三、多個應用對快取的影響。
通常情況下，mysql資料庫的快取是根據伺服器記憶體的大小自動分配的。如果一台伺服器上只有乙個mysql應用，那麼固然最好。不過在實際工作中，為了降低資訊化投資的成本，往往會在同一臺伺服器上布置多個資訊化應用。由於其他資訊化應用也需要使用記憶體的空間作為快取，那麼mysql資料庫中快取空間就可能變小。如果遇到這種情況下，資料庫管理員需要跟系統工程師進行協商，為各種不同的應用根據效能要求的不同，手工設定不同的快取空間。如此的話，就可以避免同一臺伺服器上不同資訊化應用對快取的衝突。
合理使用快取
乙個優秀的專案，其中必然使用到了快取機制 乙個 遇到效能瓶頸是，第乙個解決方案一般是使用快取，快取的應用面特別廣，無論是客戶端，還是應用伺服器，或是儲存伺服器。快取一般存放讀寫比價頻繁，變化較少的資料，應用程式讀取資料時先從快取中讀取資料，獲取不到再訪問資料庫，再放到快取中，以便於下次快速獲取。快取...
合理利用快取檔案
不要把所有都變成想當然，當你要給成幾萬幾十萬幾百萬使用者展示乙個資訊的時候。你會去資料庫中資訊的表給所有使用者都插入一條資訊麼？我想打多數人不會那麼幹吧，但有時候就想當然了，一條是這麼幹 20條肯定也是這麼幹的。這樣就陷入了乙個誤區。轉變一下思維，給乙個人肯定是就只給20個使用者中的乙個人只讓他自己...
mysql 配置查詢快取
開啟查詢快取 需要在 mysql 的配置 query cache size 10m query cache type 1 query cache type 0或off關閉快取 1或on開啟快取，但是不儲存使用sql no cache的select語句 例子select sql no cache co...