一、問題現(xiàn)象

• 內(nèi)存占用異常：通過top命令發(fā)現(xiàn)MySQL進程（mysqld）占用了90.7%的物理內(nèi)存（56.5G/62G）。
• 系統(tǒng)負載：CPU使用率較低（1.3%），但內(nèi)存幾乎耗盡。

二、核心排查步驟

1. 參數(shù)檢查

• MySQL版本：8.0.39（未開啟慢查詢?nèi)罩荆?/li>
• 關鍵內(nèi)存參數(shù)：

  SHOW VARIABLES LIKE 'innodb_buffer_pool_size';  -- 12G（配置較低，建議調整為總內(nèi)存的70%~80%）
  SHOW VARIABLES LIKE 'tmp_table_size';           -- 16M（臨時表內(nèi)存限制過?。?
  

• 臨時文件路徑：/tmp（建議改為專用目錄以避免性能問題）。

2. 內(nèi)存使用分析

• 全局內(nèi)存統(tǒng)計：

  SELECT SUM(CAST(replace(current_alloc,'MiB','') AS DECIMAL(10,2))) 
  FROM sys.memory_global_by_current_bytes 
  WHERE current_alloc LIKE '%MiB%';
  

  結果：總內(nèi)存使用約1933.69MB。

• 分事件內(nèi)存占用：

  SELECT event_name, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED)
  FROM performance_schema.memory_summary_global_by_event_name
  ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 10;
  

  關鍵發(fā)現(xiàn)：

  • memory/innodb/buf_buf_pool占用13.29GB（InnoDB緩沖池）。
  • memory/group_rpl/Gcs_xcom::xcom_cache占用1024MB（復制相關緩存）。

• 用戶級內(nèi)存統(tǒng)計：

  SELECT user, event_name, current_number_of_bytes_used/1024/1024 AS MB_USED
  FROM performance_schema.memory_summary_by_account_by_event_name
  WHERE host <> "localhost"
  ORDER BY MB_USED DESC LIMIT 10;
  

  發(fā)現(xiàn)：特定用戶（如zqzh）在memory/temptable/physical_ram中占用65MB。

3. 存儲過程/函數(shù)/視圖檢查

• 存儲過程與函數(shù)：

  SELECT Routine_schema, Routine_type 
  FROM information_schema.Routines 
  WHERE Routine_schema NOT IN ('mysql','information_schema','performance_schema','sys');
  

  結果：多個業(yè)務庫存在大量存儲過程和函數(shù)（如bpc、bsc等）。

• 視圖與觸發(fā)器：

  SELECT TABLE_SCHEMA, COUNT(TABLE_NAME) FROM information_schema.VIEWS;
  SELECT TRIGGER_SCHEMA, COUNT(*) FROM information_schema.triggers;
  

  結果：視圖和觸發(fā)器數(shù)量較少，非主要內(nèi)存消耗源。

4. 操作系統(tǒng)級檢查

• 進程內(nèi)存占用：

  ps -eo user,pid,vsz,rss | grep mysqld
  

  結果：mysqld進程虛擬內(nèi)存（VIRT）96.2G，物理內(nèi)存（RES）56.5G。

• 內(nèi)存映射分析：

  pmap -d <mysql_pid> | tail -1
  

  關鍵指標：

  • writeable/private：進程實際占用的私有內(nèi)存（持續(xù)增長可能提示內(nèi)存泄漏）。

• 透明大頁（THP）檢查：

  cat /sys/kernel/mm/transparent_hugepage/enabled
  

  結果：THP處于開啟狀態(tài)（可能導致內(nèi)存分配效率低下）。

三、解決方案

1. 調整MySQL配置

• 增加InnoDB緩沖池：

  innodb_buffer_pool_size = 48G  -- 根據(jù)總內(nèi)存（62G）調整為77%
  

• 優(yōu)化臨時表內(nèi)存：

  tmp_table_size = 256M
  max_heap_table_size = 256M
  

2. 關閉透明大頁（THP）

• 臨時關閉：

  echo never > /sys/kernel/mm/transparent_hugepage/enabled
  echo never > /sys/kernel/mm/transparent_hugepage/defrag
  

• 永久關閉：
  在/etc/rc.local中添加：

  if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
      echo never > /sys/kernel/mm/transparent_hugepage/enabled
  fi
  if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
      echo never > /sys/kernel/mm/transparent_hugepage/defrag
  fi
  

3. 優(yōu)化查詢與存儲過程

• 分析慢查詢：開啟慢查詢?nèi)罩?，定位低效SQL。
• 減少存儲過程依賴：將復雜邏輯移至應用層，避免存儲過程內(nèi)存泄漏。

4. 硬件與環(huán)境優(yōu)化

• 增加物理內(nèi)存：若業(yè)務需求增長，考慮升級服務器內(nèi)存。
• 遷移臨時文件目錄：將tmpdir設置為專用高速存儲路徑。

四、總結

• 核心問題：MySQL內(nèi)存使用率高主要由InnoDB緩沖池配置不足、THP機制效率低下及存儲過程/函數(shù)內(nèi)存占用引起。
• 解決重點：調整緩沖池大小、關閉THP、優(yōu)化查詢邏輯。
• 后續(xù)監(jiān)控：通過sys.memory_global_by_current_bytes和pmap持續(xù)觀察內(nèi)存變化。

通過以上步驟，可顯著降低MySQL內(nèi)存占用并提升穩(wěn)定性。

附：為了解決高內(nèi)存占用問題，可以采取以下措施

1. 仔細審查并調整MySQL的其他內(nèi)存相關配置項，確保它們合理且與系統(tǒng)資源匹配。
2. 監(jiān)控并分析MySQL的實際內(nèi)存使用情況，使用如SHOW ENGINE INNODB STATUS;和performance_schema來獲取更詳細的內(nèi)存使用報告。
3. 考慮調整操作系統(tǒng)的內(nèi)存管理策略，比如調整THP設置或使用/proc/sys/vm/swappiness來調整內(nèi)存交換行為。
4. 如果確定內(nèi)存分配合理，且應用確實需要這么多內(nèi)存來保證性能，那么可能需要接受較高的內(nèi)存占用率作為正?，F(xiàn)象，或考慮增加服務器物理內(nèi)存。

到此這篇關于MySQL內(nèi)存使用率高問題排查過程以及解決方案的文章就介紹到這了,更多相關MySQL內(nèi)存使用率高問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論