MySQL的查詢快取功能現已成了瓶頸！

標籤：產品經理   伺服器   可擴充性   穩定性   輸送量   

650) this.width=650;" class="aligncenter wp-image-70519" src="http://www.linuxprobe.com/wp-content/uploads/2017/06/mysql-300x150.jpg" alt="MySQL的查詢快取功能現已成了瓶頸！MySQL的查詢快取功能現已成了瓶頸！" width="448" height="224" title="MySQL的查詢快取功能現已成了瓶頸！MySQL的查詢快取功能現已成了瓶頸！" style="vertical-align:middle;height:auto;margin:10px auto;" />
如果你在網上搜尋一下“tuning MySQL query cache”（最佳化MySQL查詢快取），看到那麼多的結果以及有人提供的五花八門的建議，這則新聞也就並不完全令人驚訝了。

正如MySQL Server的產品經理摩根·托克（Morgan Tocker）在這裡撰寫的那樣，問題在於可擴充性。

緩衝的操作看起來簡單得很：SELECT（選擇）命令儲存在一個雜湊表（又叫散列表，hash table）中；如果入站請求與雜湊匹配，伺服器就能返回上一次查詢執行的結果（並且有保護機制，那樣伺服器不會返回過時陳舊的結果。）

托克寫道，問題在於，“眾所周知，面對多核機器上的高輸送量工作負載，緩衝無法很好地擴充。”

他繼續寫道，就算這個問題能夠得到解決，解決辦法也無法讓查詢快取的效能變得更易於預測（言外之意就是變得更穩定）；對於面向使用者的系統來說，效能的穩定性常常比峰值輸送量來得更重要。

MySQL Server的一群開發人員已決定“致力於其他更普遍適用於所有工作負載的改進方法”，而不是堅持修複緩衝問題。

果真需要緩衝機制的開發人員可以使用ProxySQL，升級到MySQL 8.0的其他使用者“將被鼓勵使用伺服器端Query Rewrite（查詢重寫）。”

本文出自 “12629896” 部落格，請務必保留此出處http://12639896.blog.51cto.com/12629896/1933612

MySQL的查詢快取功能現已成了瓶頸！