最近有些生產服務器老是mysql內存不停得往上漲，開發人員和維護反饋，用了不少的臨時表，問題時常線上發生，測試又一直比較難重現。
經觀察mysql內存的os占用趨勢，發現從8：40開始，mysql內存逐漸上升，到下午1：30左右差不多占了整個系統90%多的物理內存。在業務較為繁忙的時間，還發生過好幾次oom導致被killed的情形。
經過分析配置，innodb_buffer_pool_size配置並不高，差不多50%，其他log_buffer，additional_mem，key_buffer，query_cache都不怎么高。加起來也不到兩三百兆。並發、join_size這些也不算很高。實際比算下來最大還超過1GB多。
為了查看memory引擎的臨時表的內存占用，升級到了percona server版本。
SELECT * FROM information_schema.`GLOBAL_TEMPORARY_TABLES`;
SELECT SUM(data_length+index_length)/1024/1024 FROM information_schema.global_temporary_tables WHERE ENGINE='memory';
可看到臨時表消耗了300M內存。
而在該實例中，buffer_pool為默認，128M。
可見臨時表消耗的mysql內存遠比buffer pool size要大得多。
知道內存的具體去處之后，針對性解決就是細節性的優化了。