摘要:性能未必所有場合總是會改善性能當有大量的查詢和大量的修改時,機制可能會造成性能下降。緩存機制的內(nèi)存使用使用內(nèi)存池技術(shù),自己管理內(nèi)存釋放和分配,而不是通過操作系統(tǒng)。內(nèi)存池使用的基本單位是變長的一個的通過鏈表把這些串起來。
轉(zhuǎn)自:https://www.cnblogs.com/lpfut...
介紹mysql Query Cache 默認為打開。從某種程度可以提高查詢的效果,但是未必是最優(yōu)的解決方案,如果有的大量的修改和查詢時,由于修改造的cache失效,會給服務器造成很大的開銷,可以通過query_cache_type【0(OFF)1(ON)2(DEMAND)】來控制緩存的開關(guān).
需要注意的是mysql query cache 是對大小寫敏感的,因為Query Cache 在內(nèi)存中是以 HASH 結(jié)構(gòu)來進行映射,HASH 算法基礎就是組成 SQL 語句的字符,所以 任何sql語句的改變重新cache,這也是項目開發(fā)中要建立sql語句書寫規(guī)范的原因吧
何時cachemysql query cache內(nèi)容為 select 的結(jié)果集, cache 使用完整的 sql 字符串做 key, 并區(qū)分大小寫,空格等。即兩個sql必須完全一致才會導致cache命中。
prepared statement永遠不會cache到結(jié)果,即使參數(shù)完全一樣。在 5.1 之后會得到改善。
where條件中如包含了某些函數(shù)永遠不會被cache, 比如current_date, now等。
date 之類的函數(shù)如果返回是以小時或天級別的,最好先算出來再傳進去。
select * from foo where date1=current_date -- 不會被 cache select * from foo where date1="2008-12-30" -- 被cache, 正確的做法
太大的result set不會被cache (< query_cache_limit)
何時更新一旦表數(shù)據(jù)進行任何一行的修改,基于該表相關(guān)cache立即全部失效。
為什么不做聰明一點判斷修改的是否cache的內(nèi)容?因為分析cache內(nèi)容太復雜,服務器需要追求最大的性能。
性能
ache 未必所有場合總是會改善性能
當有大量的查詢和大量的修改時,cache機制可能會造成性能下降。因為每次修改會導致系統(tǒng)去做cache失效操作,造成不小開銷。
另外系統(tǒng)cache的訪問由一個單一的全局鎖來控制,這時候大量>的查詢將被阻塞,直至鎖釋放。所以不要簡單認為設置cache必定會帶來性能提升。
大result set不會被cache的開銷
太大的result set不會被cache, 但mysql預先不知道result set的長度,所以只能等到reset set在cache添加到臨界值 query_cache_limit 之后才會簡單的把這個cache 丟棄。這并不是一個高效的操作。如果mysql status中Qcache_not_cached太大的話, 則可對潛在的大結(jié)果集的sql顯式添加 SQL_NO_CACHE 的控制。
query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache
緩存機制的內(nèi)存使用mysql query cache 使用內(nèi)存池技術(shù),自己管理內(nèi)存釋放和分配,而不是通過操作系統(tǒng)。內(nèi)存池使用的基本單位是變長的block, 一個result set的cache通過鏈表把這些block串起來。因為存放result set的時候并不知道這個resultset最終有多大。block最短長度為query_cache_min_res_unit, resultset 的最后一個block會執(zhí)行trim操作。
使用步驟
修改配置文件,設置query_cache_type和query_cache _size,以及query_cache_min_res_unit(可以采用默認值)
query_cache_type 0 代表不使用緩沖, 1 代表使用緩沖,2 代表根據(jù)需要使用。
如果query_cache_type=1,如果不需要緩沖,則query如下
SELECT SQL_NO_CACHE * FROM my_table WHERE ...
如果query_cache_type=2,如果需要緩沖,則query如下
SELECT SQL_CACHE * FROM my_table WHERE ...總結(jié)
Query Cache 在提高數(shù)據(jù)庫性能方面具有非常重要的作用。
其設定也非常簡單,僅需要在配置文件寫入兩行: query_cache_type 和 query_cache _size,而且 MySQL 的 query cache 非??欤《乙坏┟?,就直接發(fā)送給客戶端,節(jié)約大量的 CPU 時間。
當然,非 SELECT 語句對緩沖是有影響的,它們可能使緩沖中的數(shù)據(jù)過期。一個 UPDATE 語句引起的部分表修改,將導致對該表所有的緩沖數(shù)據(jù)失效,這是 MySQL 為了平衡性能而沒有采取的措施。因為,如果每次 UPDATE 需要檢查修改的數(shù)據(jù),然后撤出部分緩沖將導致代碼的復雜度增加。
使用場景
寫操作少于讀操作;數(shù)據(jù)實時性要求較強(即不允許緩存中存在過期數(shù)據(jù))
如果允許緩存中存在過期數(shù)據(jù),可以自己使用Redis等工具進行緩存
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/62006.html
摘要:但是這將嚴重影響程序的性能。垂直分區(qū)的優(yōu)點在于可以使得行數(shù)據(jù)變小,在查詢時減少讀取的數(shù),減少次數(shù)。此外,垂直分區(qū)可以簡化表的結(jié)構(gòu),易于維護。垂直分區(qū)的缺點在于主鍵會出現(xiàn)冗余,需要管理冗余列,并會引起操作,可以通過在應用層進行來解決。 Java面試通關(guān)手冊(Java學習指南,歡迎Star,會一直完善下去,歡迎建議和指導):https://github.com/Snailclimb/Jav...
摘要:串行最高的隔離級別,完全服從的隔離級別。但是這將嚴重影響程序的性能。此外,垂直分區(qū)可以簡化表的結(jié)構(gòu),易于維護。 我自己總結(jié)的Java學習的一些知識點以及面試問題,目前已經(jīng)開源,會一直完善下去,歡迎建議和指導歡迎Star: https://github.com/Snailclimb/Java_Guide 書籍推薦 《高性能MySQL : 第3版》 文字教程推薦 MySQL 教程(菜鳥教程...
閱讀 1830·2021-10-09 09:44
閱讀 2703·2021-09-22 15:38
閱讀 2499·2021-09-09 09:33
閱讀 703·2021-09-07 09:58
閱讀 1830·2021-09-02 15:41
閱讀 2515·2019-08-30 15:55
閱讀 1804·2019-08-30 15:55
閱讀 549·2019-08-30 15:44