《MySQL面試小抄》查詢快取機制終面
我是肥哥，一名不專業的面試官！
我是囧囧，一名積極找作業的小菜鳥！
囧囧表示：小白面試最怕的就是面試官問的知識點太籠統，自己無法快速定位到關鍵問題點！！！
本期主要面試考點
面試官考點之簡述一下什么是查詢快取機制？
面試官考點之查詢如何命中快取？
面試官考點之什么場景下SQL和結果集不會被快取？
面試官考點之什么場景下會導致MySQL快取失效？
面試官考點之查詢快取是如何進行記憶體管理的？
面試官考點之MySQL是一次性分配所有的記憶體空間嗎？
面試官考點之快取中的記憶體碎片無法避免，那么有什么辦法優化嗎？
面試官考點之MySQL4.0提出了查詢快取，它設計出來是為了加速哪些查詢場景？
面試官考點之MySQL5.6中默認禁用，8.0以后完全移除，造成這個改變的原因是什么？
面試官考點之生產環境要不要開啟MySQL快取？
面試官考點之簡述一下什么是查詢快取機制？
MySQL服務器高負載情況下，我們需要采取一種措施給服務器減輕壓力，一個復雜的查詢是非常消耗性能的，
其中磁盤IO又占據主要資源，快取是對系統性能優化的一種重要手段，
查詢快取機制設計是為了從根本上減少磁盤IO次數，MySQL開啟快取后，將SQL和結果集以鍵值對KV的形式存盤在記憶體中，
當相同的SQL再次進入，MySQL識別是相同查詢喉，會直接回傳快取在記憶體中的結果集，
避免再次進行一系列復雜的決議優化和磁盤IO程序，
面試官考點之查詢如何命中快取？
select id from user;
?
select id FROM user;
上面陳述句能命中快取嗎？
MySQL快取命中機制有嚴格苛刻的要求，在判斷命中前，MySQL不會對SQL做任何的決議處理，
SQL上的任何字符的不同，如大小寫、空格、注釋等都會導致快取不命中
所以上面查詢時無法命中快取的，
面試官考點之什么場景下SQL和結果集不會被快取？
或者說快取規則是什么？
第一種情況：查詢陳述句中包含不確定資料
例如查詢陳述句中包含不確定函式：NOW()、CURRENT_DATE()等，
?
因為每次執行這類帶了不確定資料的查詢所回傳結果可能是不同的，
第二種情況：超過了query_cache_limit預設閾值
超出了快取記憶體能承受的范圍，將放棄快取！
面試官考點之什么場景下會導致MySQL快取失效？
任何對于表結構或者表資料的更新操作，一定會造成查詢快取中的資料失效，同時查詢快取值的相關條目也會被清空，
MySQL判定有更新操作，就會設定所有的查詢快取失效，
面試官考點之查詢快取是如何進行記憶體管理的？
MySQL服務啟動，快取機制會在記憶體中開辟一塊記憶體，
其中會劃分出一塊區域專用來管理維護快取資料的元資料，
例如空間記憶體、資料表和查詢結果的映射，SQL和查詢結果的映射
MySQL快取機制將剩余的空閑空間分為一個個小資料塊，用來存盤快取結果，
每個小塊中存盤自身的型別，大小和查詢結果資料，還有指向前后記憶體塊的指標
面試官考點之MySQL是一次性分配所有的記憶體空間嗎？
MySQL因為無法預知查詢結果大小，所以無法為每個查詢結果精確分配大小恰好匹配的快取空間，
MySQL快取機制采用的是邊查邊存，動態的去申請快取記憶體，
一條SQL查詢快取分配記憶體程序是怎么樣的？
當有查詢結果需要快取的時候，MySQL快取機制會在SQL查詢開始（還未得到結果）時就去申請一塊記憶體空間（小資料塊），在不斷查詢中，如果發現不夠則繼續申請，如果存盤完時有空余則釋放多余的記憶體空間，
如果余下的需要回收的空間很小，小于query_cache_min_res_unit，不能再次被使用，可能會造成記憶體碎片，影響查詢性能，
面試官考點之快取中的記憶體碎片無法避免，那么有什么辦法優化嗎？
沒有什么辦法能夠完全避免記憶體碎片，但是選擇合適的
query_cache_min_res_unit
可以減少由碎片導致的記憶體空間浪費，
值太小，則浪費的空間更少，但是會導致頻繁的記憶體塊申請操作
如果設定得太大，那么碎片會很多
調整合適的值其實是在平衡記憶體浪費和CPU消耗
那么我如何確定這個平衡值？
可以通過記憶體實際消耗，計算單個查詢的平均快取大小
（query_cache_size - Qcache_free_memory）/ Qcache_queries_in_cahce
通過查看閑置記憶體塊數量（Qcahce_free_blocks）來觀察碎片，
如果產生的碎片過多，通過什么方法可以整理碎片？
通過FLUSH_QUERY_CAHCE清理碎片
?
這個命令將所有的查詢快取重新排序，
?
并將所有的空閑空間都聚焦到查詢快取的一塊區域上，
面試官考點之MySQL4.0提出了查詢快取，它設計出來是為了加速哪些查詢場景？
1、并發性和查詢QPS不高 2、被訪問的底層資料本質上是靜態或半靜態的 3、查詢密集型應用，更新頻率非常低而只讀查詢頻率非常高的場景
面試官考點之MySQL5.6中默認禁用，8.0以后完全移除，造成這個改變的原因是什么？
理想情況下，上述查詢場景非常適合使用查詢快取，但是實際的業務系統都是有CRUD操作的，
在MySQL里QC是由一個全域鎖在控制，每次更新QC的記憶體塊都需要進行鎖定，資料更新頻繁，就會不斷的失效快取操作，同時快取失效會造成大量的查詢快取碎片化，還會導致服務器的負載升高，影響資料庫的穩定性，
所以MySQL官方經過抉擇，果斷移除了查詢快取模塊，
面試官考點之生產環境要不要開啟MySQL快取？
建議不開啟
根據MySQL官方的測驗，如果對一個表執行簡單的查詢，
?
設定每次查詢都不一樣，
?
打開QC后，性能反而下降了13%左右
當然實際業務中，不會都是這種不同的請求，因此實際影回應該比這個小一些，
MySQL查詢快取的目的是為了提升查詢性能，但它本身也是有性能開銷的，
需要在合適的業務場景下（讀寫壓力模型）使用
不合適的業務場景不但不能提升查詢性能，查詢快取反而會變成MySQL的瓶頸，
?
對寫密集型的應用場景來說，禁用快取反而提高性能，
隨緣更新，整理不易，歡迎聯系小白討論，大神巴巴請繞路！
更多精彩內容，歡迎關注微信公眾號：囧么肥事 (或搜索：jiongmefeishi)
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/286065.html
標籤：MySQL
上一篇：MYSQL資料庫重新初始化
下一篇：每日一道SQL題