MySQL內存使用排查

　　MySQL使用內存上升90%！在運維過程中50%的幾率，會碰到這樣的問題。算是比較普遍的現象。

　　MySQL內存使用率過高，有諸多原因。普遍原因是使用不當，還有MySQL本身缺陷導致的。到底是哪方面的問題，那就需要一個一個進行排查。

　　下面介紹排查思路： 1.參數配置需要確認，內存是否設置合理

　　MySQL內存分為全局和線程級：

　　備注：query_cache_size 8.0版本已經廢棄掉了。 2.存儲過程&函數&觸發器&視圖

　　目前積累的使用經驗中，存儲過程&函數&觸發器&視圖 在MySQL場景下是不適合的。性能不好，又容易發現內存不釋放的問題，所以建議盡量避免。 MySQL 5.7 MySQL 8.0 3.系統庫統計查詢

　　備注：有必要統計用戶級別內存，因為很多環境對接了第三方插件，模擬從庫，這些插件容易內存不釋放。

　　備注：找到對應問題事件或線程后，可以進行排查，解決內存高的問題。 4.系統工具查看內存 1）top命令

　　顯示系統中各個進程的資源占用狀況。

　　2）free命令

　　free-h 命令顯示系統內存的使用情況，包括物理內存、交換內存(swap)和內核緩沖區內存。 3）ps命令

　　MySQL相關進程使用內存情況。 4）pmap 命令

　　pmap是Linux調試及運維一個很好的工具，查看進程的內存映像信息。 用法1：執行一段時間記錄數據變化，最少20個記錄，下面22837是MySQL pid 用法2：linux 命令pmap MySQL pid導出內存，下面22837是MySQL pid

　　RSS就是這個process實際占用的物理內存。

　　Dirty: 臟頁的字節數（包括共享和私有的）。

　　Mapping: 占用內存的文件、或[anon]（分配的內存）、或[stack]（堆棧）。

　　writeable/private：進程所占用的私有地址空間大小，也就是該進程實際使用的內存大小。

　　1.首先使用/top/free/ps在系統級確定是否有內存泄露。如有，可以從top輸出確定哪一個process。

　　2.pmap工具是能幫助確定process是否有memory leak。確定memory leak的原則：writeable/private (‘pmap –d’輸出）如果在做重復的操作過程中一直保持穩定增長，那么一定有內存泄露。 總結

　　對于MySQL內存泄露來說:

　　以上排查里都沒有找到原因，可以換下服務器或主從切換觀察。也可以進行版本升級（代價不小）。

　　如能提供一個實際環境，也可以一步一步進行調試，抓取內存變化，確定是什么導致內存泄露的問題。之后提交bug，讓官方提供修復。

　　墨天輪原文鏈接：https://www.modb.pro/db/86827