前言

生産環境中，MySQL 不經意間吃掉全部的內容，然後開始吃掉 SWAP，性能一降再降，怎麽辦？

爲什麽吃掉那麽多內存？

可以從下面三點查看原因：

1 – Python、PHP、Java應用，配置不當，或使用未優化的查詢，編碼過于複雜。

2 – MySQL配置不當，導致內存效率低下或內存浪費。

3 – 計算機內存低于服務器上的進程所需的內存，也就是“供不應“”。

怎麽辦？優化 MySQL 配置項。

MySQL 使用內存，有兩個途徑。

永久占用的內容

比如全局緩沖區（Global Buffer）類別，是在服務器啓動期間從操作系統獲得的，不會釋放到任何一個別的進程。

動態請求的內存

線程緩沖區由MySQL使用，它是在處理新查詢時從操作系統請求的內存。在執行查詢之後，該內存被釋放回操作系統。

這意味著 MySQL 的內存使用，是全局緩沖區加上線程緩沖區以及允許的最大連接數。

對于專用數據庫服務器，該值需要保持在服務器內存的90%以下。在共享服務器的情況下，它應該保持在服務器內存的50%以下。

重點配置項

檢查一下 MySQL 設置，有助于確定內存使用情況，從而爲 MySQL 分配合適的值。

innodb_buffer_pool_size

緩存在InnoDB存儲的緩沖池中完成。緩沖池的大小對系統性能起著關鍵作用，並被指定爲可用RAM的50-70%之間的值。如果池大小太小，將導致頁面過度刷新，如果太大，將由于內存競爭而導致交換。

key_buffer_size

在 MYISAM 存儲引擎的情況下，此參數有助于確定緩存，需要根據RAM設置KEY_BUFFER_SIZE，其大小約爲RAM大小的20%。

max_connections

爲了在任何時刻爲 MySQL 分配盡可能多的連接數，並避免單個用戶使服務器過載，需要使用max_connections。每個線程使用RAM的一部分進行緩沖區分配，因此它根據RAM的大小限制最大連接數。

一個近似的公式：

 max_connections = (Available RAM – Global Buffers) / Thread Buffers
 最大連接數 = （有效內存 - 全局緩沖容量）/ 線程緩沖容量

query_cache_size

當不經常更改且Web服務器接收許多相同查詢時，查詢高速緩存可能會很有用。查詢緩存將SELECT語句的文本與發送到客戶端的相應結果一起存儲。

因此，此參數僅用于此類應用程序服務器，否則將被禁用，並爲其他服務器設置爲零。

爲了避免資源爭用，盡管啓用了該功能，但應將該值設置爲10MB左右的最小值。

阻止濫用資源的程序

當網站受到攻擊時，有可能在短時間內建立異常高的連接數量。MySQL 中的 PROCESSLIST 可用于檢測頂級用戶並阻止對濫用連接的訪問。

優化查詢語句

找出查詢需要很長時間才能執行的語句，因爲這些查詢需要進一步優化服務器才能更好地執行，可以通過服務器查詢日志進行識別。由于查詢速度慢，導致磁盤讀取較多，導致內存和CPU使用率較高，影響服務器性能。

升級內存

最後，到了加內存條的時候了。雖然在優化數據庫設置之後，服務器會不斷地路由到使用交換內存，但也必須增加內存。俗話說：“巧婦難爲無米之炊”，就是這個意思。

寫在最後

上面說的這些方向，大家可以在實際操作中驗證體會，希望大家在數據庫優化的路上，麻溜順暢，砥砺前行。

我是@程序員小助手，持續分享編程與程序員成長相關的內容，歡迎關注~~