max_connections引數對mysql初始化記憶體的影響

今天發現mysql的max_connections 引數的大小對mysql記憶體初始化大小影響非常大；

公司的amp監控專案元件越來越多，部署需要的記憶體也越來越多，測試環境下，兩年前4G記憶體就能跑的應用，現在8G都不夠用，經常發生oom-killer，而且因為物理機資源已經超量分配，導致虛擬機器頻繁掛掉，嚴重影響了研發與測試的進度；

今天過了一遍所有應用的記憶體配置，修改了部分應用jvm的記憶體大小設定，節省了不少記憶體，最後發現mysql啟動後就佔用了1.3G記憶體，因為是研發與功能測試環境，對效能要求不高，於是就開始對mysql開刀；

首先發現innodb_buffer_pool_size=1G,於是將其更改為512M，重啟後發現記憶體只減少了200多M，比較納悶為什麼不是減少了512M；

繼續優化，使用show status引數檢視了下開啟表的快取，發現預設值如下：

 table_definition_cache =1400
 performance_schema_max_table_instances=12500
table_open_cache=2000

於是將其設定為以下值

performance_schema_max_table_instances=200
table_definition_cache=200
table_open_cache=128

重啟後發現又減少了將近200M，但是還是佔用了了將近1G的記憶體；
然後有檢查了下各種cache的預設值，發現都不大，很納悶這些記憶體都是哪裡佔用的；
最後注意到my.cnf檔案裡面配置了max_connections引數過大：

max_connections = 5000

竟然是5000，嘗試將其更改為500後，記憶體竟然馬上下降到了283M，真驚喜啊，沒想到這個引數對mysql初始化記憶體影響這麼大；